You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Antonio D'Errico (JIRA)" <ji...@apache.org> on 2012/05/07 12:05:48 UTC
[jira] [Created] (AMQ-3830) RAR Transacted Message Delivery (Option
B JCA Spec 13-30) fail to manage Timeoutexception
Antonio D'Errico created AMQ-3830:
-------------------------------------
Summary: 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.
--
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
[jira] [Commented] (AMQ-3830) RAR Transacted Message Delivery
(Option B JCA Spec 13-30) fail to manage Timeoutexception
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (AMQ-3830) RAR Transacted Message Delivery (Option
B JCA Spec 13-30) fail to manage Timeoutexception
Posted by "Antonio D'Errico (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio D'Errico updated AMQ-3830:
----------------------------------
Description:
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.
was:
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.
Patch Info: Patch Available
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira