activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From frank_at_zynga <>
Subject Re: Transacted Messages Not Committed
Date Fri, 23 Jan 2009 21:18:56 GMT

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.


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 <>:
>> 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:
>> Sent from the ActiveMQ - User mailing list archive at
> -- 
> Open Source SOA

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message