Hi Gary, I was able to create a test case and reproduce this behavior on a consistent basis. The source code is attached and is actually nearly identical to the code we're using in production. While running through some test scenarios I was able to discover some additional information:
- The problem *only* occurs when the number of consumer threads is greater than 1. I found this out by accident. - The problem occurs whether or not a correlation ID is used on the messages. I wasn't sure if this mattered or not, but it doesn't. Fortunately, as a result of working with this test case I discovered a work around to the problem, which is to not only call session.commit() on successful message processing but to then call message.acknowledge() as well. This works like a charm, but it was my understanding that calling message.acknowledge() was not necessary when using transacted sessions. Please correct me if I'm wrong. Also, I suspect this behavior might be due to something funky I'm doing with my code, but it seems very straightforward to me. Thanks, -Frank http://www.nabble.com/file/p21632842/AMQWorkerTest.java AMQWorkerTest.java http://www.nabble.com/file/p21632842/AMQWorkerTest.java AMQWorkerTest.java Gary Tully wrote: > > Hi Frank, > do you think you can produce a test case for the behavior you describe. > Thanks, > Gary. > > 2009/1/22 frank_at_zynga <fr...@zynga.com>: >> >> 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. >> >> > > > > -- > http://blog.garytully.com > > Open Source SOA > http://FUSESource.com > > -- View this message in context: http://www.nabble.com/Transacted-Messages-Not-Committed-tp21615994p21632842.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
