-
15. Re: Management changes for 2.2
gaohoward Oct 18, 2010 3:22 AM (in response to clebert.suconic)Thanks Clebert. I agree we shouldn't hard code the jms-client-id. But we cannot dump everything in the metadata to the getJSon. For example, we add a 'jms-initial-session' metadata to mark the special ServerSession and this should not be dumped to the connection info.
Another issue I'm not sure is the producer information we are going to provide. As Jeff suggested instead of providing producers info, we provide ServerSessions per address. I wonder if those information are of any interests to the users. Because the ServerSessions are in Horentq Server core, not something a user should concern. I need to verify with you and jeff about it before going on.
Howard
-
16. Re: Management changes for 2.2
jmesnil Oct 18, 2010 9:19 AM (in response to gaohoward)I agree with clebert, let's dump everything we have in the metadata. It'll make for simpler code and if users add metadata specific to their applications, they will be able to use the management API to see these metadata.
HornetQ admins are interested to know who is sending messages to the server.
At the minimum, we should be able to identify the sessions which sent messages from whose which consumes them.
It's simple to identify a session with consumers (there are corresponding ServerConsumer on the server) but we need also to identify sessions which sent messages. Furthermore, if they sent messages to an address corresponding to a JMS destination name, it is likely they correspond to a JMS producer on the client side.
Does that make sense?
-
17. Re: Management changes for 2.2
clebert.suconic Oct 18, 2010 9:50 AM (in response to gaohoward)For example, we add a 'jms-initial-session' metadata to mark the special ServerSession and this should not be dumped to the connection info
Huh?
what is this jms-initial-session?
Aren't you misusing the meta-data? The metadata is used by the user to identify the session.
Say, if the user has a special usage for the Session on his store, he could add metadata with the store-id on the ServerSession. Things like that.
You're not supposed to use it for application's metadata.
Also, regarding the producer, I'm not sure what's the signature on the methods, but you could provide things like getAddresses()[] getCountForAddress(addressName), instead of creating multiple sessions.
-
18. Re: Management changes for 2.2
gaohoward Oct 18, 2010 10:15 AM (in response to jmesnil)Jeff,
I think the session metadata is introduced to help track jms connections' clientIDs and user principals. i.e. when user invokes listConnectionsASJSon() the returned value will contains 'clientID' and 'userPrincipal'. Dumping the metadata for a server session should be provided as a separate management method, something like listServerSessionsMetadataAsJSon(). what do you think?
About the producer info, I think for the moment it's fine to provide method for retrieving which server session sends what messages, just as you said.
Another question: it seems you have already added the JMS Destination MBean functionalities, right? According to JIRA 416, those functionalities are
* number of pending messages
* absolute number of message published (through message metrics)
* absloute number of message removed (through message metrics)which correspond to the destinations attributes DeliveringCount, MessageAdded, and removeMessage() method respectively. Am I right?
-
19. Re: Management changes for 2.2
gaohoward Oct 18, 2010 10:22 AM (in response to clebert.suconic)Hi Clebert,
"jms-initial-session" corresponds to the initialSession in every HornetQConnection. We use this session to store metadata called "ClientID" and "UserPrincipal" for this connection. When user invoke listConnectionsASJSon(), those information are retrieved from this special session. So those metadata are not actually belongs to the Session, rather it belongs to the JMS connection.
Re: Also, regarding the producer, I'm not sure what's the signature on the methods, but you could provide things like getAddresses()[] getCountForAddress(addressName), instead of creating multiple sessions.
Not sure what you meant by those methods, are you recommending additional functionalities? For now, I'm going to implement this piece of work as Jeff suggested.
Thanks.
-
20. Re: Management changes for 2.2
clebert.suconic Oct 18, 2010 1:25 PM (in response to gaohoward)you shouldn't dump the jms-initial-session on the metadata.
if you do it, you will be leaking JMS-concepts into core, which is actually why we started with the meta-data.
All you need is to add the metadata for each created session.
On the JMS-wrapper, you could copy all the metadata from the initial session to the additional sessions.
You could also have a metadata on the initialSession, such as is-initial-session=true
or something like that.
I will look for you on IRC later tonight so we talk over about this.
-
21. Re: Management changes for 2.2
gaohoward Oct 19, 2010 8:03 AM (in response to jmesnil)Management Interfaces for ServerSession
In order to satisfy producer side information retrieving, I think the following API should be provided at JMS Server MBean
1. List listSessions(); -- returns a list of server session IDs
2. List listSessions(String connectionID); -- returns all the server sessions that belong to the connection identified by connectionID (already there)
3. List listTargetDestinations(String sessionID); -- returns a list of addresses to which the designated server session has sent messages.
4. String getLastSentMessageID(String address); -- returns the last sent message's ID of the given addressWhat do you think guys?
-
22. Re: Management changes for 2.2
gaohoward Oct 19, 2010 8:06 AM (in response to gaohoward)On second thought, the first listSessions() may not be of much use.
-
23. Re: Management changes for 2.2
clebert.suconic Oct 19, 2010 9:59 AM (in response to gaohoward)I think it would be better to keep it meta-like.
listSession(String attribute, String value)
listTargetDestinations(String attribute, String value)
-
24. Re: Management changes for 2.2
clebert.suconic Oct 19, 2010 11:28 AM (in response to clebert.suconic)Unless you're talking about JMS Control. On that case it would be ok to have listSession(String connectionID);
I thought you were talking about the ServerSessions interfaces.
you have to do it meta-like whenever you add metadata operations to core components.
-
25. Re: Management changes for 2.2
gaohoward Oct 19, 2010 11:08 PM (in response to clebert.suconic)Yes I'm refering to JMS Control. Thanks.
-
26. Re: Management changes for 2.2
gaohoward Oct 21, 2010 2:38 AM (in response to gaohoward)Correction:
4. String getLastSentMessageID(String address); -- returns the last sent message's ID of the given address
There is one parameter missing, it should be:
String getLastSentMessageID(String sessionID, String address);
-
27. Re: Management changes for 2.2
gaohoward Oct 21, 2010 4:40 AM (in response to gaohoward)Also I'd like to change this operation
List listSessions(String connectionID);
To:
String listSessionsAsJSon(String connectionID) to include session's creation time.