activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Transacted Messages Not Committed
Date Mon, 26 Jan 2009 10:41:43 GMT
Hi Frank,
it is great to have a test case. Could you create a jira issue[1] for
this and attach your tests case with the ASF license grant. In that
way we can use your test case in the activemq test suite to ensure
this issue stays fixed when it is resolved.



2009/1/23 frank_at_zynga <>:
> Hmmm, one of the files didn't get uploaded.  Let me try again...
> frank_at_zynga wrote:
>> 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
>> 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


Open Source SOA

View raw message