It turns out that not only is this a bug, it is known bug:
https://issues.apache.org/jira/browse/AMQ-3059
I created a test case and commented on the above issue with reference to
the test case.
I'll start another thread for discussing a workaround.
</Mattias>
Dejan Bosanac wrote (2012-11-19 11:00):
Hi Mattias,
can you raise Jira with these details, so that it doesn't get lost in
the emails. Also, it'd be ideal to have a test case that reproduce the
issue if possible.
Regards
--
Dejan Bosanac
----------------------
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosa...@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Sat, Nov 17, 2012 at 11:34 AM, Mattias Jiderhamn
<mattias.jiderh...@expertsystems.se> wrote:
I've spent quite some time trying to figure out why ActiveMQ retry does not
work for us with JTA, and I may finally have found the reason.
In org.apache.activemq.ActiveMQMessageConsumer.registerSync() there is a
synchronization registered, that would handle the rollback (specifically
deliveredMessages.clear()) so that message is not considered to be
delivered, but can be redelivered.
However, in out case the JTA transaction of the ActiveMQ consumer is
suspended and later resumed, before it is rolled back.
JTA specification
(http://download.oracle.com/otndocs/jcp/jta-1.1-spec-oth-JSpec/?submit=Download)
section 3.2.3:
"When the application's transaction context is resumed, the application
server ensures that the resource in use by the application is again enlisted
with the transaction. Enlisting a resource as a result of resuming a
transaction triggers the Transaction Manager to inform the resource manager
to re-associate the resource object with the resumed transaction
(XAResource.start(TMRESUME))."
So when JTA transaction is resume()d the Resin JTA transaction manager calls
org.apache.activemq.TransactionContext.start(), in which the the
synchronizations list is set to null!
It seems to me that some JTA implementations do not call XAResource.start()
on resume() even though the spec says so (the way I read it), which may
explain why this works for some people.
Would anyone agree if I claim there is a bug in ActiveMQ, that prevents it
from working properly with resumed JTA transactions...?
</Mattias>
