Does the JBM bridge uses a connection pool?

[henk53]

Hi,

I'm trying to get a connection pool to work for accessing a remote JBM queue from another JBM (JBoss AS 5.1) instance. I was looking at the bridge mechanism for this.

For instance, this example is taken from the JBM docs:

<mbean code="org.jboss.jms.server.bridge.BridgeService" name="jboss.messaging:service=Bridge,name=TestBridge" xmbean-dd="xmdesc/Bridge-xmbean.xml">
     <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoader,name=MyRemoteJMSProvider</depends>
     <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
     <attribute name="SourceDestinationLookup">/queue/testQueue</attribute>
     <attribute name="TargetDestinationLookup">/queue/A</attribute>
     <attribute name="QualityOfServiceMode">0</attribute>

     <attribute name="MaxBatchSize">5</attribute>
     <attribute name="MaxBatchTime">-1</attribute>
     <attribute name="FailureRetryInterval">5000</attribute>
     <attribute name="MaxRetries">-1</attribute>
     <attribute name="AddMessageIDInHeader">false</attribute>
</mbean>

This however has 'provider loaders' as an argument, and thus not something that resembles a structure that is created by the tx-connection-factory element in a -ds.xml file.

According to an article written by Tim Fox (http://community.jboss.org/wiki/ShouldIcacheJMSconnectionsandJMSsessions) my performance "*will suck*", if I don't use a connection pool. It goes without saying that I don't want my performance to suck, but everything I read about connection pools only seems to apply to local destinations. Using the bridge was my last resort to get connection pooling to my remote queue, but this too does not seem to use a connection pool.

What gives?

[atijms]

henk de boer wrote:

According to an article written by Tim Fox (http://community.jboss.org/wiki/ShouldIcacheJMSconnectionsandJMSsessions) my performance "*will suck*", if I don't use a connection pool.

I was struggeling with the same thing, and as it appears the Bridge doesn't use a connection pool, but uses a different kind of pattern so it actually doesn't really need one. This pattern is not unlike e.g. a request queue for AJAX requests in JSF 2 and RichFaces, where instead of letting each part of the code sent something on its own (with or without a connection pool), all requests are collected in a single queue and sent out in batches by a single thread.

In fact, in our own software I have implemented the exact same pattern. We have tens to hundreds of small write requests per second, and originally we let each thread where the write request originated write to a DB directly. Of course there was a connection pool in between (for JDBC these are actually easy and actually work ). This didn't scale very well, even though a connection pool was thus used.

So I rebuild the architecture to let all threads post their write requests to a single queue, which is read by 3 threads having a single fixed connection each to the DB, via which they sent the write requests in batches. (in case of many cores in both the client and DB and having sufficiently fast storage in the DB, we found 3 consumers for this queue to work more optimally than 1).

I scanned through the org.jboss.jms.server.bridge.Bridge code and found it basically does the following (omitting details about xa/non-xa, username/no username, etc):

1. Get source and target destinations from JNDI
2. Get source connection factory from JNDI
   1. Create connection
   2. Create session
   3. Create consumer(sourceDestination)
3. Get target connection factory from (remote) JNDI
   1. Create connection
   2. Create session
   3. Create producer(null)
4. consumer.setMessageListener(SourceListener)
5. SourceListener onMessage:
   1. Get global lock
   2. Put message in list
   3. If batch size reached
      1. For each message in list
         1. producer.send(targetDestination, message)

That's basically it. Apart from a very small hack to optimize forward_mode_xa if the source is jboss messaging, it's all just the pure and simple JMS API that's being used by the bridge. No JBoss internal magic and no JCA pools for remote connections.

Nevertheless, even in this case where the bridge uses a single fixed connection, it might be handy to have a connection pool anyway. Namely, such a pool could take care of validating that connections are still valid and destroy a connection and reconnect if needed.

[atijms]

p.s.

The above information is of course for the JMS bridge. If you're connecting two JBM instances the core bridge, which doesn't use the JMS API, may actually be the better choice.