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 org.apache.activemq.ActiveMQXAConnectionFactoryTest#testVanilaTransactionalProduceReceive
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: http://svn.apache.org/viewvc/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/ActiveMQXAConnectionFactoryTest.java?view=markup 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 <damjan.ku...@gmail.com> 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: > http://activemq.2283324.n4.nabble.com/Duplicate-acknowledge-when-using-XA-transactions-tp4661141p4661157.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- http://redhat.com http://blog.garytully.com
