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
