Which is better: PooledConnectionFactory or CachingConnectionFactory?

Question

We use Spring (3.2.4) with ActiveMQ (5.8.0) in Tomcat (7.0.41) and it is not clear what the best usage. We want to use JmsTemplate to produce and MessageListenerContainer to receive messages.

Should we use caching in receiver side? (related link)
Works CachingConnectionFactory with ActiveMQ and failover? (related link)
Need to set useAsyncSend="true" when we use PooledConnectionFactory? (related link)

Primitive

I've used CachingConnectionFactory for message production (JmsTemplate) and consumption (DefaultMessageListenerContainer) for well over a year with Spring (3.0.7), ActiveMQ (5.5.0) and Tomcat and not experienced any issues. Generally, my consumer processes a message from queue_1 and finishes by publishing a message to queue_2, but queue interactions use the same CachingConnectionFactory. – Tame

Answer 1

From here:

The difference between the PooledConnectionFactory and the CachingConnectionFactory is a difference in implementation. Below are some of the characteristics that differ between them:

• Although both the PooledConnectionFactory and the CachingConnectionFactory state that they each pool connections, sessions and producers, the PooledConnectionFactory does not actually create a cache of multiple producers. It simply uses a singleton pattern to hand out a single cached producer when one is requested. Whereas the CachingConnectionFactory actually creates a cache containing multiple producers and hands out one producer from the cache when one is requested.

• The PooledConnectionFactory is built on top of the Apache Commons Pool project for pooling JMS sessions. This allows some additional control over the pool because there are features in Commons Pool that are not being used by the PooledConnectionFactory. These additional features include growing the pool size instead of blocking, throwing an exception when the pool is exhausted, etc. You can utilize these features by creating your own Commons Pool GenericObjectPool using your own customized settings and then handing that object to the PooledConnectionFactory via the setPoolFactory method. See the following for additional info: http://commons.apache.org/pool/api-1.4/org/apache/commons/pool/impl/GenericObjectPoolFactory.html

• The CachingConnectionFactory has the ability to also cache consumers. Just need to take care when using this feature so that you know the consumers are cached according to the rules noted in the blog post.

• But most importantly, the CachingConnectionFactory will work with any JMS compliant MOM. It only requires a JMS connection factory. This is important if you are using more than one MOM vendor which is very common in enterprise organizations (this is mainly due to legacy and existing projects). The important point is that the CachingConnectionFactory works very well with many different MOM implementations, not only ActiveMQ.

From here:

• If you have clustered ActiveMQs, and use failover transport it has been reported that CachingConnectionFactory is not a right choice.

• The problem I’m having is that if one box goes down, we should start sending messages on the other, but it seems to still be using the old connection (every send times out). If I restart the program, it’ll connect again and everything works. Source: Autoreconnect problem with ActiveMQ and CachingConnectionFactory

• The problem is that cached connections to the failed ActiveMQ was still in use and that created the problem for the user. Now, the choice for this scenario is PooledConnectionFactory.

• If you’re using ActiveMQ today, and chances are that you may switch to some other broker (JBoss MQ, WebSphere MQ) in future, do not use PooledConnectionFactory, as it tightly couples your code to ActiveMQ.

Wisner

This is a good overall description of the two factory, but I would add a few comments: Should we use caching in receiver side? I have found in ActiveMQ in Action book that this is not necessary. Works CachingConnectionFactory with ActiveMQ and failover? "Autoreconnect problem..." link contained are 2 opposing answers, but it seems that the PooledConnectionFactory will definitely work, so we will use that (we do not plan to use another MOM). Need to set useAsyncSend="true" when we use PooledConnectionFactory? We still do not know, but it should not be a problem if it is set. :) – Primitive

Async sends: tells a producer not to block waiting for an ack for each message sent: activemq.apache.org/async-sends.html (I think it shouldn't be a problem) – Wisner

I think it's better to ask your new questions in a different question ;) – Wisner

CachingConnectionFactory extends SingleConnectionFactory and SingleConnectionFacotury's documentation says "A JMS ConnectionFactory adapter that returns the same Connection from all createConnection() calls". So, if it returns the same connection all the times then how come it is said to be performing connection pooling? What is the practical difference between connection pooling and session pooling? – Berstine

Answer 2

But disadvantage of spring implementation - it does not supports XA transactions. But activemq implementation supports it (XAPooledConnectionFactory). So, i'd say if you using JMS with other resources and even with another jms broker and want do it transacted - use activemq implementation. And of course, PooledConnectionFactory will work with any JMS compliant MOM too

Mouldon