6 Replies Latest reply on Feb 18, 2009 11:50 AM by jmesnil

    invmacceptor auto created in remotingserviceimpl

    timfox

       

      // when JMX is enabled, it requires a INVM acceptor to send the core messages
       // corresponding to the JMX management operations (@see ReplicationAwareStandardMBeanWrapper)
       if (jmxEnabled)
       {
       boolean invmAcceptorConfigured = false;
       for (TransportConfiguration config : transportConfigs)
       {
       if (InVMAcceptorFactory.class.getName().equals(config.getFactoryClassName()))
       {
       invmAcceptorConfigured = true;
       }
       }
       if (!invmAcceptorConfigured)
       {
       transportConfigs.add(new TransportConfiguration(InVMAcceptorFactory.class.getName(), new HashMap<String, Object>(), "in-vm"));
       }
       }
      


      I don't understand why it's necessary....

      If you want to send a management message from inside the server, no need for a session factory. just create a serversession directly and use that.

      Also I notice that *gulp* you're creating a new session for every invocation in replicationAwareInvoke.

      That's a performance killer!

        • 1. Re: invmacceptor auto created in remotingserviceimpl
          jmesnil

          I'm not sure to understand your suggestion.

          How do I create a ServerSession? Using MessagingServerIml.createSession() does not return the created session but a CreateSessionResponseMessage (and I need to find the correct RemotingConnection required to create the session).
          I need to get the ServerSession instance, wrap the client message in a SessionSendMessage packet, and pass the packet to the serverSession so that the message is correctly replicated.
          Am I missing something more obvious?

          The advantage of the current code is that I can treat sending the management messages like a simple client (as long as I can rely on having a InVM acceptor which is not a big deal imho).

          I will fix the code to not create a new session for every invocation though.

          • 2. Re: invmacceptor auto created in remotingserviceimpl
            timfox

            Add a new method on messagingserver that returns the serversession if you need to.

            And when sending a message just create the servermessage and call handleSend() - again you can expose a version that doesn't need the packet.

            • 3. Re: invmacceptor auto created in remotingserviceimpl
              timfox

              Ok no probs, I can make the change here

              • 4. Re: invmacceptor auto created in remotingserviceimpl
                jmesnil

                it's crazy how such a trivial change can be more complex than envisioned.

                If I want to cache the client session for the duration of the management object life, I also need to close it cleanly at the end of its life.
                I can't do that from JMX (the method is not exposed from the mbean) so I need to keep a registry of these objects in the ManagementServiceImpl so that I can close their client session properly when unregistering the resource.

                I agree that the code as it is is a performance killer. But what kind of performance are we talking about? This code will be called every time a mbean operation is invoked which means that there will be a network trip between the JMX client and the server every time. This seems to me like premature optimization. In that specific case, I'd prefer to trade performance for code simplicity (i.e. create the client session for every invocation).

                • 5. Re: invmacceptor auto created in remotingserviceimpl
                  timfox

                  You can cache the session in the managementservice which has a well defined start and stop, and all the controls can use the same session.

                  • 6. Re: invmacceptor auto created in remotingserviceimpl
                    jmesnil

                     

                    "timfox" wrote:
                    You can cache the session in the managementservice which has a well defined start and stop, and all the controls can use the same session.


                    I did that but there is one caveat: the management service is stopped after the remoting service. The session will not be closed properly when the management service is stopped but destroyed on the "server" side when the remoting service is stopped.

                    I've added a FIXME and commented the code to clean the session properly in ManagementServiceImpl.stop().
                    We will revise it later if we use a server session.