Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
5.11.0, 5.14.5
-
None
-
None
-
Tomcat 8, ActiveMQ 5.11.0 or 5.14.5, Spring Framework 4.3, Java 7.
Description
While investigating about a memory leak I have in production (about which I wrote both at https://stackoverflow.com/questions/54143172/configuring-activemq-properly-to-avoid-producer-memory-leaks and http://activemq.2283324.n4.nabble.com/Help-with-memory-leak-td4746710.html, with no reply at all), which I hope is related to AMQ-6603 (please advise!), I discovered that, as stated by Christopher L. Shannon on that issue, it's not advisable to use a pooling/caching connection factory with a Spring message container. Reading Spring DefaultMessageListenerContainer Javadoc confirms this. However, ActiveMQ documentation says exactly the opposite at http://activemq.apache.org/spring-support.html:
Spring's MessagListenerContainer should be used for message consumption. This provides all the power of MDBs - efficient JMS consumption and pooling of the message listeners - but without requiring a full EJB container.
You can use the activemq-pool org.apache.activemq.pool.PooledConnectionFactory for efficient pooling of the connections and sessions for your collection of consumers, or you can use the Spring JMS org.springframework.jms.connection.CachingConnectionFactory to achieve the same effect.
This indeed drove me to the wrong direction.
So, I think ActiveMQ documentation should be clear about it, if org.apache.activemq.pool.PooledConnectionFactory and org.springframework.jms.connection.CachingConnectionFactory should be used only when writing message producers and/or when dealing with JmsTemplate,
Please also note that Spring Integration JMS message-driven inbound channel adapter is impacted as well, because it uses a DefaultMessageListenerContainer by default, unless otherwise configured.