JmsTemplate, part of Core Spring JMS framework, simplifies the use of JMS since it handles the creation and release of resources when sending or synchronously receiving messages. As discussed in this post – https://singztechmusings.wordpress.com/2011/04/24/problem-with-creating-jms-messageproducer-using-spring-jmstemplate-how-to-solve/ – we need to have pooling in place to make it efficient.
We’ve got two JMS provider choices: ActiveMQ‘s PooledConnectionFactory or Spring’s own CachingConnectionFactory
They’re meant for the same purpose – to pool Connection, Session and MessageProducer instances. But we need to consider a thing or two before deciding to use one of these:
1. If you have clustered ActiveMQs, and use failover transport (Eg. failover:(tcp://firstbox:61616,tcp://secondbox:61616)?timeout=30000), 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: http://stackoverflow.com/questions/5916638/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.
2. 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.
Singaram Subramanian
singztechmusings.wordpress.com 