activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Duplicate acknowledge when using XA transactions
Date Wed, 02 Jan 2013 15:49:17 GMT
that does look wrong. I wonder if you could wrangle up a testcase?

There are some existing unit tests that have most of the angles covered,
for example

I tried a quick rollback variant but did not reproduce the unmatched ack
with trunk.

They use raw jms/xa apis to drive the scenarios so they only exercise
activemq but I think they are straight forward to understand and extend.
The interesting bits may be the order or close/rollback in a spring context.

See the code:

Failing a unit test based on the above, a simple spring context that
captures the use case will suffice.

On 28 December 2012 11:11, damjankumar <> wrote:

> I found out why the msg ack with transactionId=null was sent after the XA
> transaction finished processing the same message. When the MessageConsumer
> is closed, the method ActiveMQMessageConsumer.deliverAcks() is called.
> There is a check if a session's ack mode is auto acknowledge, if the
> isAutoAcknowledgeEach() is true, the ack is send (even when the session is
> transacted):
> void deliverAcks() {
>         MessageAck ack = null;
>         if (deliveryingAcknowledgements.compareAndSet(false, true)) {
>             if (isAutoAcknowledgeEach()) {...
> }
> This check isAutoAcknowledgeEach is always true for any XA transaction,
> because ActiveMQXASession has its method isAutoAcknowledge always returning
> true. Please just let me know if this is a bug, or I am doing something
> totally wrong.
> Tnx.
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message