[
https://issues.apache.org/activemq/browse/AMQ-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Snyder updated AMQ-2717:
------------------------------
Fix Version/s: 5.5.0
(was: 5.4.1)
> Crashing and restarting the broker causes message redelivery even if the XA
> transaction was already prepared (but not commited)
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-2717
> URL: https://issues.apache.org/activemq/browse/AMQ-2717
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.3.1
> Reporter: Eugene Rodos
> Fix For: 5.5.0
>
> Attachments: XATransactionRecoveryTest.java
>
>
> The scenario is as follows:
> \- message is delivered within an XA global transaction
> \- the XA tx completes the prepare phase
> \- the server crashes before the XA tx completes the commit
> \- the server is restarted
> \- (if the J2EE server supports XA recovery, it will recover the XA tx and
> complete the commit (tested and confirmed with Websphere))
> \- ActiveMQ redelivers the message
> The redelivery should not happen. Unless, following recovery, the
> TransactionManager decides to rollback the tx, the tx will be committed. If
> it is committed, the message would have been processed already. Redelivering
> it causes the message to be processed again and breaks JMS'
> deliver-once-and-only-once guarantee.
> If the tx has been prepared, AMQ should not redeliver the message following a
> crash recovery, If the tx is ultimately rolled back and the message is put
> back on the queue, it can redeliver it, otherwise, it should not.
> This is very difficult to write a Junit test for but I will try to come up
> with something...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
