3

As per Apache camel's documentation, we should set Cache level to CACHE_CONSUMER to gain better performance while dealing with non-XA transactions. Probably they did so, as PooledConnectionFactory doesn't cache consumers.

In place of PooledConnectionFactory, I am using Spring's CachingConnectionFactory because PooledConnectionFactory is some what coupled with ActiveMQ and I am dealing with IBMMQ.

CachingConnectionFactory on the other hand, caches producers and consumers as well. So I hope in this case, there is no point in setting the cache level of JmsComponent to CACHE_CONSUMER.

Please correct me if I am wrong. Any advice would be of great help

Raju Parashar
  • 312
  • 4
  • 17

2 Answers2

3

Good afternoon,

Your understanding is largely correct. Note that when you apply CACHE_CONSUMER to the listening component, this means that the Spring JMS message listener should cache the message consumer (somewhat obviously). Caching the consumer requires that the Spring JMS message listener also caches the JMS session and connection.

If you want to use a transacted endpoint, the responsibility for this caching has to be taken away from the Spring JMS message listener. In the transacted case, you externalize the caching connection factory. This is why the level defaults to CACHE_NONE if transacted is true.

When you set transacted to true and provide a connection factory, a JMS transaction manager is created that works with the connection factory to manage transactions. This is why the Spring JMS message listener can not manage the consumer/session/connection.

The first answer is correct, using the CachingConnectionFactory will get you caching that you want and also will externalize the caching away from the Spring message listener container. Which allows the transaction manager to have access to the JMS session.

Doug Grove
  • 962
  • 5
  • 5
2

Yes, I feel your understanding is right here.

As stated in one of the comment of this blog,

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.

By caching at the consumer level i.e. setting CACHE_CONSUMER, it implies that the connection, the session and the consumer is cached.

However, by using CachingConnectionFactory, as documented, you get both consumer and producer caching defaulted to true and also gain control over them, if needed. Hence no more cache level is required.

Additional help : Camel Docs

Saiprasad Bane
  • 477
  • 4
  • 9
  • I am worried about the fact that CACHE_AUTO fallsback to CACHE_NONE when JMSComponent is transacted. So even if I use CachingConnectionFactory, will those cached consumers be picked up even if cache level is CACHE_NONE ? – Raju Parashar Apr 26 '20 at 13:57
  • As per my understanding, here it must get defaulted to `CACHE_CONSUMER` rather than `CACHE_AUTO`. – Saiprasad Bane Apr 26 '20 at 17:42
  • It would really be a great help, if someone from camel group comments here and confirms the same – Raju Parashar Apr 27 '20 at 04:41