activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (AMQ-2717) Crashing and restarting the broker causes message redelivery even if the XA transaction was already prepared (but not commited)
Date Fri, 01 Jun 2012 11:14:23 GMT

     [ https://issues.apache.org/jira/browse/AMQ-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary Tully resolved AMQ-2717.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 5.6.0
         Assignee: Gary Tully

fixed via https://issues.apache.org/jira/browse/AMQ-3305
                
> 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/jira/browse/AMQ-2717
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.3.1
>            Reporter: Eugene Rodos
>            Assignee: Gary Tully
>             Fix For: 5.x, 5.6.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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message