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

Rob Davies resolved AMQ-2191.
-----------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 5.3.0)
                   5.4.0

Fixed on 5.4 by revision 921822 and on 5.3.1 vy SVN revision 921844

> Incorrect handling of interruptions during commit or rollback of a transaction
> ------------------------------------------------------------------------------
>
>                 Key: AMQ-2191
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2191
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.3.0
>         Environment: Java 1.6.0_02
> Kubuntu Linux  2.6.24-22
> Bitronix Transaction Manager 1.3.2
>            Reporter: Michael Gottschalk
>            Assignee: Rob Davies
>             Fix For: 5.4.0
>
>         Attachments: ACTIVEMQ-PATCH, activemq_interruption_fix.diff, 
> xa-jms-exception.txt
>
>
> We have a process framework that sends interruptions to threads that should 
> be stopped or paused. Some of these threads interact with ActiveMQ, so 
> interruptions can occur inside ActiveMQ at different points.
> A problem occurs if the interruption is detected in 
> ActiveMQConnection.syncSendPacket during commit or rollback of a transaction. 
> ActiveMQ then throws a JMSException so that it appears to Bitronix as if the 
> XA transaction is in an inconsistent state (see stacktrace in the attached 
> file).
> In our opinion, the interruption should be ignored by ActiveMQ during the 
> critical commit or rollback phase. It is not mandatory that an interruption 
> has an immediate effect. Especially such a non-interruptable step as rollback 
> or commit should be performed even though an interruption occurs.
> I created a patch for the class TransactionContext which, in case of an 
> interruption, resets the interruption state of the thread, retries the 
> syncSendPacket method call and restores the thread's interruption state 
> afterwards. In this manner, no inconsistent state exceptions occur in the 
> transaction manager any longer and interruption is deferred until the 
> commit/rollback has succeeded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to