So there are a few concerns with the code. First off, to your question of consumption stopping - based on the fact that the code uses ActiveMQResourceAdapter, I assume this is running in the context of a JTA Transaction. If so, all operations are transacted, and the client acknowledge mode is ignored. Based on this, I suspect that the messages are not getting acknowledged properly since the connections are getting closed before the transaction can complete.
Secondly, JMS is connection-oriented, meaning it expects, and works well with, long-lived connections. It does not work well with short-lived connections (unlike REST). When used within an EJB, or the like, the solution of adapting the one-shot connection to perform well with JMS is to use connection pools. Consumer and producer caching may be appropriate/necessary as well as their creation is also not light-weight. To determine if my theory here on the cause of your problem is correct, take a look at the enqueue and dequeue counts for the queue - using the webconsole or a JMX tool (such as jconsole or jvisualvm). Thinking about this a little more, it may also be the case that the messages are hitting their redelivery limits. Try changing connection setting parameters for prefetch to 1 to check this. If that helps (it may not 100% eliminate it, but should at least increase the number of messages processed), then again - connection pooling and consumer caching are needed. -- View this message in context: http://activemq.2283324.n4.nabble.com/activemq-consumer-does-not-return-data-even-when-queue-not-empty-tp4708474p4708475.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
