You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Joachim Glink (Jira)" <ji...@apache.org> on 2022/10/06 11:19:00 UTC

[jira] [Commented] (AMQ-7485) RAR managed producer is unaware of timed out transaction; sends non transacted message in error

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

Joachim Glink commented on AMQ-7485:
------------------------------------

[~gtully]  I came across this change because I experienced a different behavior in our application after upgrading to AMQ 5.16.x

In the org.apache.activemq.ra.ManagedTransactionContext class you´ve added
{code:java}
public boolean isRollbackOnly() {
    return sharedContext.isRollbackOnly() || super.isRollbackOnly();
} {code}
All the other methods in this class do the call on the sharedContext only in case that the useSharedContext flag is set to true, e.g.
{code:java}
public void commit() throws JMSException {
    if (useSharedTxContext) {
        sharedContext.commit();
    } else {
        super.commit();
    }
} {code}
 

In our environment (Wildfly with AMQ RAR), I have a strange behavior that a Producer#send fails because of a "transaction marked as rollback only" even if we do the send without a transaction. (I don´t have a simple reproducer for it and until know I´m only able to reproduce the situation in our full-running system.)

If I reset the AMQ version to 5.14.x or change the ManagedTransactionContext#isRollbackOnly() and do the check on the _sharedContext_ only in case of useSharedContext=true, the message sending works.

So I wonder why the check isn´t done on this method.

Thanks

> RAR managed producer is unaware of timed out transaction; sends non transacted message in error
> -----------------------------------------------------------------------------------------------
>
>                 Key: AMQ-7485
>                 URL: https://issues.apache.org/jira/browse/AMQ-7485
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: RAR, XA
>    Affects Versions: 5.15.0
>         Environment: JEE RAR
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>            Priority: Major
>              Labels: RAR, XA, xaresource
>             Fix For: 5.16.0
>
>
> There is a problem with a RAR managed connection enlisted in a xa transaction that aborts, if that connection is used to produce messages.
> getConnection succeeds and enlists the resource, the session is in an xa transaction, all is good. 
> If however, the transaction times out and aborts, *before* a producer gets to send(), the send will *not* see a transaction context and will produce a message with no transaction identity in error.
> The abort forces an end(fail) and rollback, however this results in the transaction context being unset and the producer session not being aware of the aborted transaction.
> The transaction management is external in the case of a managed connection and the default is non transactional in the absence of an external or RAR local transaction. 
> Getting a reference to the TransactionManager and doing a transaction status check before send is a workaround, but that should not be necessary.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)