activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3830) RAR Transacted Message Delivery (Option B JCA Spec 13-30) fail to manage Timeoutexception
Date Sat, 08 Sep 2012 09:56:07 GMT

    [ https://issues.apache.org/jira/browse/AMQ-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451297#comment-13451297
] 

Claus Ibsen commented on AMQ-3830:
----------------------------------

Antonia

You have marked this ticket with [x] as patch available. But there is no patches.
                
> RAR Transacted Message Delivery (Option B JCA Spec 13-30) fail to manage Timeoutexception
> -----------------------------------------------------------------------------------------
>
>                 Key: AMQ-3830
>                 URL: https://issues.apache.org/jira/browse/AMQ-3830
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Connector
>    Affects Versions: 5.5.1, 5.6.0
>         Environment: Linux - JBoss 5.5.1 or JBoss 7.1.1 - ActiveMQ 5.5.1/5.6.0
>            Reporter: Antonio D'Errico
>
> The MDB receives a message within an XA transaction.
> If a timeout occurs, the application server transaction manager move the transaction
state to aborted and after ended, rollbacking changes and resetting the transaction id. 
> Everything done after delivery of the message is resetted to its initial state.
> When, however, the control returns to ActiveMQSession the transactionContext has been
cleaned up so a new local transaction is started.
> At this point is invoked the method ServerSessionImpl.afterDelivery and the the proxy
MessageEndpoint (JBoss instance) starts the afterDelivery stuff. 
> The application server transaction manager tries to commit a transaction that is already
ROLLED_BACK and rise an exception. Returning to  ServerSessionImpl.afterDelivery the exception
is catched and is executed the finally block, the transaction context is marked as a local
so is done a local commit that remove the message from the input queue. 
> As result the message has been consumed (lost) but not processed.
> My solution to avoid this problem is to manage in different way the exception (that contains
server side information about transaction) to understand if we need to commit or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message