1 2 Previous Next 27 Replies Latest reply on Oct 21, 2010 4:40 AM by gaohoward

    Management changes for 2.2

    jmesnil

      For HornetQ 2.2, we need to enhance the management API (this is tracked by https://jira.jboss.org/browse/HORNETQ-416).

      I have started working on it in a branch (http://fisheye.jboss.org/browse/Hornetq/branches/hornetq-416/)

       

      For now, I have mainly enhanced the management API for sessions and consumers.

      We also need to add information about producers.

       

      we don't track producers on the server side. Any ServerSession can produce a message to an address.
      A server session can send messages to any address
      We could provide a list of all addresses that were sent messages from this server session.
      We could maintain a map in the AddressControl that is updated with the server session ID when
      it sends a message to the given address (performance impact?).
      The ServerSession would also have to keep a map of <address, last message published ID>

       

      We also need to retrieve this information when the user lists all the producers associated to a given JMS Connection ID

       

      Another thing which will need a refactoring is to get the client ID of a JMS Connection.

      As the name indicates, this ID corresponds to the client side and is not sent to the server. For now, it goes to the server only when creating a core queue for a durable subscriber.

      How can we indicate on the server side, the client ID corresponding to the connection on the client-side?

        • 1. Re: Management changes for 2.2
          gaohoward

          About the ClientID, I think we can just send the ID to the server when Connection.setClientID() is called.

          • 2. Re: Management changes for 2.2
            timfox

            You can't do that. HornetQ core is JMS agnostic. Coding knowledge of JMS stuff on the core is a big no-no.

            • 3. Re: Management changes for 2.2
              leosbitto

              Tim Fox wrote:

               

              You can't do that. HornetQ core is JMS agnostic. Coding knowledge of JMS stuff on the core is a big no-no.

               

              What about extending the HornetQ core with one optional String (clientID) then? That seems like a big yes-yes to me to enable better monitoring of JMS clients (and possibly the core clients, too, if they set this clientID) on the HornetQ server side...

              • 4. Re: Management changes for 2.2
                clebert.suconic

                We could maybe add a metadata on the Session. Users would be able to add anything they want to their CoreSession and we would be able to manage it at the server.

                 

                I think that would be useful. An user could add the metadata such as:

                 

                clientSession.addMetaData("CustomerCode", "Clebert");

                 

                On the visualization, you would see more detailed data than just the SessionID.

                 

                The JMS Layer would use this metadata concept to add set the SessionID on the metadata.

                 

                 

                just an idea!

                • 5. Re: Management changes for 2.2
                  jmesnil

                  @clebert, that's a good idea to add metadata to Core session.

                   

                  This way, we could flag the client session with a JMS client ID that'd be stored on the server side with the ServerSession.

                   

                  This is a more elegant solution that we could use for other JMS resources.

                  For example to know if a Core ServerConsumer corresponds to a JMS Consumer, I must parse its queue's name to see if it matches a JMS destination.

                  We could add metadata to Core queues too to be able to flag them (corresponds to a JMS Queue or a JMS subscription). But let's do that later for queues.

                   

                  We can add a

                  clientSession.addMetaData(String name, String value) to the API and a new wireformat packet.

                  On the server side, let's add a Map to ServerSession that the management API can query.

                  • 6. Re: Management changes for 2.2
                    gaohoward

                    Right, current way will obviously polute the core connections. I have to send a core message and add this information to the core's remoting connection.

                     

                    I'll consider Clebert's suggestion, i.e. add clientID as a metadata with ServerSession.

                    • 7. Re: Management changes for 2.2
                      clebert.suconic

                      >> +import static org.hornetq.core.protocol.core.impl.PacketImpl.CONNECTION_SET_CLIENTID;

                       

                       

                      This is wrong...  the package should be SESSION_ADD_METADATA

                       

                       

                       

                      You will have an addMetaData on the clientSession, the JMSSession will call clientSessionadddMetaData("jms.session.id","sessionID"), you will send a session_add_metadata to the server, and you will have it set on the Session

                      • 8. Re: Management changes for 2.2
                        clebert.suconic

                        Howard, looking at the diffs, you are actually implementing the setClientID at the Remoting Connection, (differently than how it should be done).

                        • 9. Re: Management changes for 2.2
                          gaohoward

                          Hi Clebert, I'm going to change that. Thanks.

                          • 10. Re: Management changes for 2.2
                            gaohoward

                            I'm trying to figure out the mapping between JMS connections and Core sessions. From client side, each JMS connection wraps several core ClientSessions. Each ClientSessions actually represents a JMS Session object. Except one initialSession, which used to authenticate the connection. At the server, there is a ServerSession corresponding to each ClientSession, there is no counterpart for a JMS Connection at the server. I'm thinking to single out the initialSession to represent the JMS Connection and stores meta data in there.

                            Except clientID, there are other informations already implemented by Jeff, I'm thinking move those information over to this server session also.

                             

                            Comments?

                            • 11. Re: Management changes for 2.2
                              jmesnil

                              Yong Hao Gao wrote:

                               

                              I'm trying to figure out the mapping between JMS connections and Core sessions. From client side, each JMS connection wraps several core ClientSessions. Each ClientSessions actually represents a JMS Session object. Except one initialSession, which used to authenticate the connection. At the server, there is a ServerSession corresponding to each ClientSession, there is no counterpart for a JMS Connection at the server. I'm thinking to single out the initialSession to represent the JMS Connection and stores meta data in there.

                              Good idea. This initial session also contains the credentials infos used to authenticate the JMS connection that we also have to display through the management API (the user info only).

                              When we create this initial session on the client and successfully authenticate the user, this would be a good place to call session.addMetaData to store the clientID on the corresponding ServerSession.

                              We also need to flag this ServerSession as the initial_jms_session (again in the metadata) so that when we will get all the sessions corresponding to a connection ID on a server, we can know which one corresponds to the initial sessions (all the others corresponding to regular JMS sessions)

                              • 12. Re: Management changes for 2.2
                                gaohoward

                                Thanks for the tip Jeff.

                                 

                                Howard

                                • 13. Re: Management changes for 2.2
                                  clebert.suconic

                                  Modified: branches/hornetq-416/src/main/org/hornetq/jms/management/impl/JMSServerControlImpl.java

                                  ===================================================================

                                  --- branches/hornetq-416/src/main/org/hornetq/jms/management/impl/JMSServerControlImpl.java     2010-10-15 11:38:17 UTC (rev 9790)

                                  +++ branches/hornetq-416/src/main/org/hornetq/jms/management/impl/JMSServerControlImpl.java     2010-10-15 12:34:13 UTC (rev 9791)

                                  @@ -739,20 +739,25 @@

                                           Set<RemotingConnection> connections = server.getHornetQServer().getRemotingService().getConnections();

                                   

                                           Set<ServerSession> sessions = server.getHornetQServer().getSessions();

                                  -         Map<Object, String> clientIDs = new HashMap<Object, String>();

                                  +        

                                  +         Map<Object, ServerSession> initialSessions = new HashMap<Object, ServerSession>();

                                  +

                                           for (ServerSession session : sessions)

                                           {

                                  -            if (session.getMetaData("jms-initial-session") != null) {

                                  -               clientIDs.put(session.getConnectionID(), session.getMetaData("jms-client-id"));

                                  +            if (session.getMetaData("jms-initial-session") != null)

                                  +            {

                                  +               initialSessions.put(session.getConnectionID(), session);

                                              }

                                           }

                                  +

                                           for (RemotingConnection connection : connections)

                                           {

                                              JSONObject obj = new JSONObject();

                                              obj.put("connectionID", connection.getID().toString());

                                              obj.put("clientAddress", connection.getRemoteAddress());

                                              obj.put("creationTime", connection.getCreationTime());

                                  -            obj.put("clientID", clientIDs.get(connection.getID()));

                                  +            obj.put("clientID", initialSessions.get(connection.getID()).getMetaData("jms-client-id"));

                                  +            obj.put("principal", initialSessions.get(connection.getID()).getUsername());

                                              array.put(obj);

                                           }

                                           return array.toString();

                                   

                                   

                                  Instead of hard code JMS-client-id on the GetJson, you should get dump everything from the metadta on the JSon.

                                   

                                  Which is actually preferred.. The only place you should have a mention to jms-client-id is while setting the clientID at the JMSSEssion. Any other usage should be just metadata and agnostic.

                                   

                                   

                                  For instance, you could do something like:

                                   

                                  for (each element on the metaata)

                                  {

                                     obj.put(metadata.key, metadata.value);

                                  }

                                  • 14. Re: Management changes for 2.2
                                    clebert.suconic

                                    I said that because say the user added some code to add his metadata. The getJSON there would contain the client's metadata as well.

                                     

                                     

                                    That's just an example. Try to avoid hard coding jms-client-id as much as possible. As I said the only place you should have it is at the JMS Session wrapper on the client.

                                    1 2 Previous Next