Thanks for the response. While that explains a lot, I'm confused as to why it was implemented that way - i.e., trying to preserve the message order. Firstly, if I have 10 JMS consumer threads and only 5 messages, there's a great chance that the order will not get preserved anyways. Secondly, if code is not written properly and exceptions are sometimes thrown, then having JMS consumer threads get stuck reprocessing messages until maxRedelivery is reached would seriously compromise scalability. Imho, it's much better that the default behaviour is to just free up that JMS consumer to process the next message.
-- View this message in context: http://activemq.2283324.n4.nabble.com/After-rollback-JMSConsumer-is-not-freed-up-to-process-other-messages-tp4657621p4657680.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
