Hi, We're just starting to phase in the use of AMQ 5.2.0 in a high volume environment and I've run into some strange behavior with transacted sessions. The basic architecture of the consumer is a java daemon that spawns a configurable number of single threaded consumers that implement MessageListener- each opens its own connection and transacted session. In the consumer onMessage() method session.commit() is being called upon successful processing of the message- and I've verified that it is actually executed. The problem is that despite the message being successfully processed and session.commit() executed the messages remain as pending in the queue. If the consumer daemon is stopped and re-started these messages are consumed again (definitely not good). Note that session.rollback() was NOT called in this scenario, all the messages were processed successfully. Also note that these are persistent messages and we are using the default AMQ message store.
I've pored over the documentation, these forums, and google results and have not come up with a diagnosis. I have observed and read up on the issue where if you're using a prefetch size of > 0 then a session rollback will block any additional consumption of messages by that session until the original problematic message is committed or sent to the dead letter queue. However, this is not the same behavior as none of the messages are rolled back. For now I've changed the consumers to use client acknowledge and that works, but we would really like to use transacted sessions if possible. Thanks, -Frank -- View this message in context: http://www.nabble.com/Transacted-Messages-Not-Committed-tp21615994p21615994.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
