1 2 3 4 Previous Next 46 Replies Latest reply on Jul 2, 2010 1:58 PM by Tim Fox

    bisocket clientMaxPoolSize vs tx-connection-factory

    arjan tijms Novice

      Hi,

       

      I would like to sent JMS messages from one JBoss AS to the other (JBoss AS 5.1 for now, JBoss AS 6 soon). As I'm worried about performance I want to make double sure that connection pooling is being used.

       

      Reading the docs I found two pointers to this:

       

      6.7. Configuring Connection Factories 

      This talks about a connection factory that is akin to a JDBC connection factory. Following JDBC best practices this should be the way to go, except that in the case of JMS a connection factory seems completely focussed on connecting to the local JMS provider, which seems to defeat the purpose a little of using a factory in the first place.

       

      6.8. Configurating the remote connector

      Here the documentation states that the underlying connector (the bisocket) also has a connection pool, which is expressed via the attribute clientMaxPoolSize.

       

      Now I wonder, if I sent JMS messages to a remote JBoss AS instance by directly requesting both the connection factory and a queue out of the JNDI of the remote server (thus not using a local connection factory), do I still get the connection pooling bennifits or is it better to use a local connection factory anyway that somehow points to the remote JMS provider?

        • 1. Re: bisocket clientMaxPoolSize vs tx-connection-factory
          Tim Fox Master

          That stuff relates to JBoss Messaging, not HornetQ.

           

          I'd ask in the JBoss Messaging forum.

          • 2. Re: bisocket clientMaxPoolSize vs tx-connection-factory
            henk de boer Master

            Tim Fox wrote:

             

            That stuff relates to JBoss Messaging, not HornetQ.

             

            Just wondering how one would do this in HornetQ then. Since HornetQ is the continued development of JBoss Messaging, and it's a JMS provider, I guess it would have a connection factory too (or more precisely, could be used with a connection facory), and of course there would have to be some kind of underlying network connector with some kind of configuration, right? (note that the TS also asked for JBoss AS 6, so I think this question is on-topic )

             

            I'd ask in the JBoss Messaging forum.

             

            I much appreciate the fairy recent re-organisation of the forum as a whole. Most sub-forums are much clearer organized. However, the JMS/Messaging sub-forums are not really optimally organized. There is the MQ forum that is grouped under JBoss AS, there is JBoss Messaging grouped under services, and finally there is HornetQ which is also grouped under services but almost as far away from JBoss Messaging as is possible (I'm sure that this is not intentional, but still).

             

            Isn't JBoss MQ the message provider up till JBoss AS 4.x, JBoss Messaging the message provider for JBoss AS 5.x and Hornet Q the one for JBoss AS 6? As such these 3 are strongly related from a user perspective and it would seem more logical to me to group these 3 together under a common heading ("JMS" maybe?).

            • 3. Re: bisocket clientMaxPoolSize vs tx-connection-factory
              Yong Hao Gao Master

              JBoss MQ, JBoss Messaging and HornetQ are messaging systems but each has a different and independent code base. They are developed and maintained by different people and in different product stage of lifecycle.

               

              I'm not quite sure about MQ, but JBoss Messaging is in maintenance mode only, meaning not new features to be added, only critical bug fixes. HornetQ is the latest messaging system.

               

              Howard

              • 4. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                arjan tijms Novice

                henk de boer wrote:

                (note that the TS also asked for JBoss AS 6, so I think this question is on-topic )

                 

                Indeed, we're curently deploying on JBoss AS 5.1, but we're going to migrate to JBoss AS 6 as soon as possible. I'm thus very interested in how this works for HornetQ.

                • 5. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                  Tim Fox Master

                  arjan tijms wrote:

                   

                  henk de boer wrote:

                  (note that the TS also asked for JBoss AS 6, so I think this question is on-topic )

                   

                  Indeed, we're curently deploying on JBoss AS 5.1, but we're going to migrate to JBoss AS 6 as soon as possible. I'm thus very interested in how this works for HornetQ.

                  Can you try and reformulate your question in the context of HornetQ? Right now I am not really sure what you are asking.

                  • 6. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                    arjan tijms Novice

                    Tim Fox wrote:


                    Can you try and reformulate your question in the context of HornetQ? Right now I am not really sure what you are asking.

                     

                    I would like to let clients on one JBoss AS 6 instance post messages to the queue of another (remote) JBoss AS 6 instance.

                     

                    In one of your articles you wrote that using a connection factory improves performance, since the pool will cache connections. I am however unable to use a connection factory for such a thing. I can set up the connection factory for the remote JBoss AS instance using one of the many examples provided, but then it seems impossible to actually use the connection to sent a message to the remote queue.

                     

                    Other messaging providers (or their resource adapter) sometimes offer a special admin object that represents the remote destination, which you can then use with a connection obtained from the local connection pool for the remote JMS provider. I can't find anything for this in either JBoss AS 5, or JBoss AS 6.

                     

                    How would I do this for JBoss AS 6 (thus HornetQ)? As indicated, I mainly tried with JBoss AS 5 until now, but as we're migrating to JBoss AS 6, information about how this can be done in HornetQ would be more valuable for the long term.

                    • 7. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                      Tim Fox Master

                      I know of no known issues doing this with HornetQ. We have detailed instructions in the docs on how to do this.

                       

                      If you come across an issue, feel free to report it as described in the "how to report an issue" wiki page.

                      • 8. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                        arjan tijms Novice

                        Tim Fox wrote:

                         

                        I know of no known issues doing this with HornetQ. We have detailed instructions in the docs on how to do this.

                         

                        I'm sorry, but which one is that exactly? (edit: the closest I came to, which is the one I also found in the JBM 2.0 beta docs, is this one: 32.4.2. Adapter Outbound Configuration. It however only explains how to get a remote connection via a pool, not how to use this to send a message to a remote destination.)

                         

                        What would I exactly use for destination then? Do I fetch this destination from the JNDI of the remote server and will it then work with the connection I fetched from the local connection pool?

                         

                        E.g.

                         

                        Suppose I have this code:

                         

                        InitialContext context = new InitialContext();
                        QueueConnectionFactory factory = (QueueConnectionFactory)context.lookup("java:/RemoteJmsXA");
                        QueueConnection connection = factory.createQueueConnection();
                        
                        QueueSession session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
                        
                        Destination destination = // *** where do I get this from? ***
                        MessageProducer producer = session.createProducer(destination);
                        ObjectMessage message = session.createTextMessage("Test from local client.");
                        producer.send(message);
                        
                        
                        

                         

                        With RemoteJmsXA a connection factory that pools remote connections. E.g.:

                         

                        <tx-connection-factory>
                            <jndi-name>RemoteJmsXA</jndi-name>
                            <xa-transaction/>
                            <rar-name>jms-ra.rar</rar-name>
                            <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
                            <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Queue</config-property>
                            <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/RemoteJMSProvider</config-property>
                            <max-pool-size>30</max-pool-size>       
                            <depends>jboss.messaging:service=ServerPeer</depends>      
                        </tx-connection-factory>
                        
                        
                        

                         

                        And RemoteJMSProvider the typical provider with javax.naming.provider.url pointing to some remote host.

                         

                        In this case, I wonder where I get the Destination from in the first code fragment. If the remote provider was WebSphere MQ, I would define an administrative object like this:

                         

                        <mbean code="org.jboss.resource.deployment.AdminObject" name="jca.wmq:name=remoteTopic"> 
                        
                         <attribute name="JNDIName">remoteTopic</attribute>
                         <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'</depends>
                         <attribute name="Type">javax.jms.Topic</attribute>
                         <attribute name="Properties">
                           persistence=NON
                           baseTopicName=myTopic
                           brokerPubQueue=SYSTEM.BROKER.DEFAULT.STREAM
                           CCSID=1208
                         </attribute>
                        </mbean>
                        

                         

                        The client code can then look up this destination from the local JNDI and use this to create the producer and send the message. But what exactly do I define or use for HornetQ here?

                         

                        I've just started looking into HornetQ, so maybe I've missed something. I did notice that HornetQ is clearly based on JBoss Messaging, as many of the classes used still seem to be the same. At least for JBoss Messaging I've waded through the source for days, but could not find anything.

                         

                        My hopes are up that HornetQ introduced something new that does make this possible and I'm eager to find out what that is.

                         

                        Thanks in advance

                        • 9. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                          henk de boer Master

                          arjan tijms wrote:

                           

                          My hopes are up that HornetQ introduced something new that does make this possible and I'm eager to find out what that is.

                           

                          Well don't get your hopes up, since HornetQ doesn't have or uses anything like the admin object you showed (I would love to be corrected on this though).

                           

                          The way it seemingly must be done in HornetQ and JBM for that matter is exactly like you mention; fetch the destination out of the JNDI from the remote server and use that. In a way this is a little counter productive if your goal is to prevent each piece of client code creating a new network connection. I'm not sure how intelligent JBoss AS is underneath with automatically caching remote JNDI connections, but I'm afraid this doesn't happen automatically.

                           

                          This leaves you with the choice of either caching the Destination object your self somewhere or just taking the hit and requesting it every time over and over. I'm not sure how thread-safe a destination really is. In JMS connections are thread-safe while sessions, producers and consumers aren't. To the best of my knowledge it's unspecified whether destinations are thread-safe, but I hope someone with more knowledge about this chimes in and gives a better answer.

                          • 10. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                            henk de boer Master

                            henk de boer wrote:

                            To the best of my knowledge it's unspecified whether destinations are thread-safe, but I hope someone with more knowledge about this chimes in and gives a better answer.

                             

                            Just updated my knowledge by simply reading the javadoc for Destination

                             

                            From the docs:

                             

                            /*
                             <P><CODE>Destination</CODE> objects support concurrent use.
                            */
                            

                             

                            and

                             

                             

                            /*
                             * <P>An administered object should not hold on to any remote resources. 
                             * Its lookup should not use remote resources other than those used by the
                             * JNDI API itself.
                             *
                             * <P>Clients should think of administered objects as local Java objects. 
                             * Looking them up should not have any hidden side effects or use surprising
                             * amounts of local resources.
                            */
                            

                             

                            So it seems they are okay to cache locally, maybe even binding them into your local JNDI tree after having requested them once.

                            • 11. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                              Tim Fox Master

                              I've stll no idea what this question is asking. If someone would like to summarise concisely, that would be great (I.e. without a long rambling email).

                               

                              If the question is whether you can create JMS destinations on the client side without looking them up from JNDI, then, yes of course you can do this.

                              • 12. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                                henk de boer Master

                                Tim Fox wrote:

                                 

                                I've stll no idea what this question is asking. If someone would like to summarise concisely, that would be great (I.e. without a long rambling email).

                                 

                                Post to a remote queue via a connection pool using a locally administered Destination object.

                                • 13. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                                  Tim Fox Master

                                  It seems to me (reading your email again) that you're asking how *JBoss AS* handles caching of connections and JNDI lookups. I.e. JEE stuff.

                                   

                                  None of these things is handled by HornetQ, it's part of JBoss AS.

                                   

                                  Regarding caching connections - this is handled by the JCA implementation in JBoss AS - there's a whole team in JBoss AS that manages that.

                                   

                                  Regarding getting references to destinations from inside EJBs, this again is handled by JBoss AS. I am no expert on JEE, but IIRC can't you configure some kind of resource-ref to reference the destination in config? Perhaps this is cached. Either way, your best bet is to ask the EJB team, All of this stuff is done in higher tier (the JEE tier) than the messaging tier. HornetQ is a messaging server that plugs into JBoss AS.

                                   

                                  Now, I do know that you can just create destination references on the fly on the client side using HornetQ. By simply using HornetQJMSClient.createXX(), or you can just use session.createQueue()/createTopic() which is part of the standard JMS API. But I don't know if that's the proper/legal *JEE* way of doing things.

                                   

                                  If you want to know JEE/JBoss AS specifics the JBoss AS teams would be in a better position to help you. We don't involve ourselves with JEE stuff that much.

                                  • 14. Re: bisocket clientMaxPoolSize vs tx-connection-factory
                                    Tim Fox Master

                                    HornetQ specific:

                                     

                                    http://hornetq.sourceforge.net/docs/hornetq-2.1.0.Final/api/

                                     

                                    or using standard JMS API:

                                     

                                    http://download.oracle.com/docs/cd/E17477_01/javaee/5/api/javax/jms/Session.html#createQueue%28java.lang.String%29

                                     

                                    In HornetQ a client side destination is really just a unique id (a String) that identifies the real destination on the server. So it's completely thread safe, can be cached etc, although there is no point caching it since you can just create it when you want it.

                                    1 2 3 4 Previous Next