Transaction suspend/resume/rollback causes maximumRedeliveries to be ignored

[Bruce Snyder <br...@gmail.com>]

I've been looking at a problem in ActiveMQ when a transaction that has
read a message from a queue is suspended, resumed and then rolled
back. This causes the maximumRedeliveries property to be ignored.
(BTW, this sequence of suspend/resume is the required functionality
for TransactionAttributeType.REQUIRES_NEW from Java EE 1.5.)

This problem came about with the Bitronix transaction manager and
there is a test case for it here:

http://jira.codehaus.org/browse/BTM-87

Although it's not a JUnit test, the BTM.zip attachment is much easier
to understand and the problem is easy to reproduce with it. I have
also tried out Atomikos with the test and I do see the problem there
as well. If you want my version of the test, let me know and I will
send it.

I've been debugging this, but it's proven to be difficult to locate.
What I see is that the redeliveryCounter on a message is incremented
inside the suspend/resume/rollback sequence causing the max
redeliveries property to be ignored. In this situation, a message
won't even make it to the DLQ because it's stuck in the cycle of
suspending/resuming/rollback and the redeliveryCounter is incremented
each time by the call to md.getMessage().onMessageRolledBack() in the
ActiveMQSession#run method. What I'm not understanding is why the
maximumRedeliveries is ignored -- any clues?

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder

Re: Transaction suspend/resume/rollback causes maximumRedeliveries to be ignored

[Bruce Snyder <br...@gmail.com>]

On Fri, Sep 24, 2010 at 9:23 AM, Bruce Snyder <br...@gmail.com> wrote:
> I've been looking at a problem in ActiveMQ when a transaction that has
> read a message from a queue is suspended, resumed and then rolled
> back. This causes the maximumRedeliveries property to be ignored.
> (BTW, this sequence of suspend/resume is the required functionality
> for TransactionAttributeType.REQUIRES_NEW from Java EE 1.5.)
>
> This problem came about with the Bitronix transaction manager and
> there is a test case for it here:
>
> http://jira.codehaus.org/browse/BTM-87
>
> Although it's not a JUnit test, the BTM.zip attachment is much easier
> to understand and the problem is easy to reproduce with it. I have
> also tried out Atomikos with the test and I do see the problem there
> as well. If you want my version of the test, let me know and I will
> send it.
>
> I've been debugging this, but it's proven to be difficult to locate.
> What I see is that the redeliveryCounter on a message is incremented
> inside the suspend/resume/rollback sequence causing the max
> redeliveries property to be ignored. In this situation, a message
> won't even make it to the DLQ because it's stuck in the cycle of
> suspending/resuming/rollback and the redeliveryCounter is incremented
> each time by the call to md.getMessage().onMessageRolledBack() in the
> ActiveMQSession#run method. What I'm not understanding is why the
> maximumRedeliveries is ignored -- any clues?

Anyone?

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder