8 Replies Latest reply on Jun 12, 2007 5:11 AM by timfox

    http://jira.jboss.org/jira/browse/JBMESSAGING-861

    sergeypk

      http://jira.jboss.org/jira/browse/JBMESSAGING-861 - Change the test framework to use remoting-service.xml configuration for testing, and drop ServiceContainer duplicate remoting configuration.

      I have an implementation of this ready but I'm not sure on certain points:

      a) the HTTP invoker is configured differently from socket-based invokers. If we are to configure the HTTP invoker from XML as well, should remoting-service.xml then be split into remoting-service-http.xml and remoting-service-bisocket.xml? Or should remoting-service.xml contain settings for both invokers?

      b) Should the bisocket configuration be shared among other socket-based invokers (socket, sslsocket, sslbisocket), or should I add a separate file for each of the invokers, thus duplicating the common settings?

      c) The way I've implemented this is I load remoting-service.xml, get hold of the configuration, fetch all attributes with isParam set and combine their keys and values to form the URL, since as far as I understand, the URL should only contain those attributes marked with isParam=true. However, serverSocketClass was originally included in the URL even though it is not marked with isParam. Is this the way it should be or is this an oversight?

        • 1. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
          ron_sigal

          Hmm. I was about to say that serverSocketClass is only used by the server and therefore doesn't need to be on the InvokerLocator. But when JBM uses the bisocket transport, there is a callback server on the client side which uses the serverSocketClass parameter to create socket wrappers.

          It turns out that the reason things work is that both serverSocketClass and clientSocketClass are configured by JMSRemotingConnection:

          metadata.put(MicroSocketClientInvoker.CLIENT_SOCKET_CLASS_FLAG,
           "org.jboss.jms.client.remoting.ClientSocketWrapper");
          metadata.put(SocketServerInvoker.SERVER_SOCKET_CLASS_FLAG,
           "org.jboss.jms.server.remoting.ServerSocketWrapper");
          


          So adding clientSocketClass to the InvokerLocator, i.e., setting isParam=true, is redundant. The point is that nothing is broken, but ideally both clientSocketClass and serverSocketClass would be treated the same. Sorry I didn't notice this before.

          • 2. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
            timfox

             

            "sergeypk" wrote:


            a) the HTTP invoker is configured differently from socket-based invokers. If we are to configure the HTTP invoker from XML as well, should remoting-service.xml then be split into remoting-service-http.xml and remoting-service-bisocket.xml? Or should remoting-service.xml contain settings for both invokers?



            Ideally we should maintain a directory somewhere which has a remoting-service-http.xml and remoting-service-bisocket.xml and remoting-service-sslbisocket.xml in it.

            The test framework should then choose one of these based upon the test config.

            The same config should also be used when building the sar file and by the examples, since we don't want to duplicate the config anywhere.


            b) Should the bisocket configuration be shared among other socket-based invokers (socket, sslsocket, sslbisocket), or should I add a separate file for each of the invokers, thus duplicating the common settings?


            See above.

            Actually we only support http, bisocket and sslbisocket in JBM so don't worry about the others, but the ones we DO support should be in their own file.


            c) The way I've implemented this is I load remoting-service.xml, get hold of the configuration, fetch all attributes with isParam set and combine their keys and values to form the URL, since as far as I understand, the URL should only contain those attributes marked with isParam=true. However, serverSocketClass was originally included in the URL even though it is not marked with isParam. Is this the way it should be or is this an oversight?


            I don't understand why you are generating a locator URI, this should be unnecessary.

            You just need to deploy the remoting connector service from the xml. Certainly there should be no need to parse the xml and manually create a URI.

            • 3. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
              sergeypk

               

              "timfox" wrote:
              I don't understand why you are generating a locator URI, this should be unnecessary.

              You just need to deploy the remoting connector service from the xml. Certainly there should be no need to parse the xml and manually create a URI.


              It just seemed to me to be the easiest thing to do. I'll work to improve this.

              • 4. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
                timfox

                 

                "sergeypk" wrote:

                It just seemed to me to be the easiest thing to do. I'll work to improve this.


                How is this easier?

                There are approx. 80 lines of code in the buildLocatorURI() method which would not be necessary if you just deployed the connector using the xml. What am I missing?

                There is a method ServiceContainer::registerAndConfigureService(...) which deploys a service given the xml. Hopefully should be able to get that to work without too much trouble.,

                • 5. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
                  sergeypk

                  It was easier because it was much less intrusive, so I could be more sure I didn't break anything. Not because the code is smaller.

                  Thanks for the registerAndConfigureService tip, I didn't notice this method. I don't think I can simply use it though, since that would deploy ConnectorMBean, but what I need is to deploy a RemotingJMXWrapperMBean which wraps the Connector and doesn't allow access to it from outside. I'll have to see how to make this work.

                  • 6. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
                    timfox

                    Why do you need to deploy the RemotingJMXWrapper rather than the ConnectorMBean?

                    • 7. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
                      sergeypk

                      That's what the code in ServiceContainer.startRemoting does currently - deploys a RemotingJMXWrapper using the same ObjectName that a Connector would normally be deployed under.

                      RemotingJMXWrapper emulates the Connector but also keeps track of some additional info that Connector doesn't provide. Here is its Javadoc:

                      * Note: This wrapper MUST NOT allow direct access to the Connector instance. This is necessary
                       * because the wrapper is maintaining the mapping between the Connector's
                       * ServerInvocationHandler instances and their subsystem names. Remoting should do that (it
                       * should have a Connector.getSubsystemNames() or similar), but it doesn't, so I have to do
                       * this by myself.
                       *
                       * @author <a href="mailto:ovidiu@jboss.org">Ovidiu Feodorov</a>


                      • 8. Re: http://jira.jboss.org/jira/browse/JBMESSAGING-861
                        timfox

                        I don't think RemotingJMXWrapper is the right way do it, but just leave it for now, since this task is not very high priority, and we don't want to spend a lot of time on it.