activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-591) Wrong XAException return code when broker timeout is hit
Date Thu, 30 Jun 2016 07:22:10 GMT


ASF GitHub Bot commented on ARTEMIS-591:

Github user bayern39 commented on the issue:
    @clebertsuconic  Hi clebert, i have considered your comment,what do you mean is that the
RM can only   find the old transactions whose lifetime are older than the default transaction
timeout by means of scanning the started transactions every transaction-timeout-scan-period
time,so it can not find the time out transactions whose privacy attribute of  timeout  is
not default transaction timeout in server and smaller than  default transaction timeout. So
when the smaller time out transaction is over, the server can not find it  immediately ,it
must await the RM scans it.Right? 
    I have communicated with the origin issue reporter,the reason why he posed the issue is
not as a trouble of specific Artemis behavior,the issue is about asking for Artemis being
better compliant with XA specification in error code.So i am considering whether it is needed
to change the  Artemis behavior , because the present solution seems have not influence.We
can still configure the  transaction-timeout-scan-period  with small value to cope with self-defined
timeout attribute.This is my point, maybe have some mistakes,What do you think about it? 

> Wrong XAException return code when broker timeout is hit
> --------------------------------------------------------
>                 Key: ARTEMIS-591
>                 URL:
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 1.3.0
>            Reporter: Chen Maoqian
> By creating testcases for checking behavior of transaction timeout I've hit an issue
of wrong error code being returned when broker transaction timeout is hit before TM transaction
timeout expires.
> It uses {{XAER_PROTO}} instead of {{RBTIMEOUT}}.
> This issue does not cause data inconsistency.
> Scenario:
> * ejb sends a message to a queue
> * processing inside of the ejb takes long time
> ** TM transaction timeout is set big enough to not hit the timeout
> ** jms broker internal transaction timeout is smaller than time needed for processing
ejb method
> * jms broker txn timeout occurs - broker local txn is rolled back
> ** txn is removed from list of broker's local in-process transactions
> * TM calls XAResource.end
> ** the call returns {{XAException.XAER_PROTO}}
> That's current implementation returns {{XAER_PROTO}} in this scenario but {{RBTIMEOUT}}
would be more appropriate.
> From discussion with Narayana developers, RM should return the most specific error return
code as possible. In this scenario it's {{RBTIMEOUT}}.
> Other notes from TM dev point of view:
> {code}
> The work represented by this transaction branch took too long."
> {code}
> _per XA spec page 39._
> The more complex question is, at what point can the resource manager forget about that
branch (and therefore return NOTA to subsequent calls)?
> The XA spec says "After the transaction manager calls xa_end(), it should no longer consider
the calling thread associated with that resource manager (although it must consider the resource
manager part of the transaction branch when it prepares the branch.)"
> which implies the branch is still considered live at that point, a view corroborated
> {code}
> "[XA_RB∗]
> The resource manager has dissociated the transaction branch from the thread of control
and has marked rollback-only the work performed on behalf of ∗xid."
> {code}
> Exception being thrown 
> {code}
> WARN  [com.arjuna.ats.jta] (Thread-0
> (ActiveMQ-client-global-threads-1468293951)) ARJUNA016056:
> TransactionImple.delistResource - caught exception during delist :
> XAException.XAER_PROTO: javax.transaction.xa.XAException
>  at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(
>  at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(
>  at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(
>  at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(
>  at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(
>  at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(
>  at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(
>  at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(
>  at
>  at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(
>  at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(
>  at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(
>  at com.arjuna.ats.arjuna.AtomicAction.commit(
>  at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(
>  at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(
>  at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(
>  at
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>  at java.lang.reflect.Method.invoke(
>  at
>  at
>  at
>  at
> Source)
>  at
> org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$
>  at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
>  at
> java.util.concurrent.ThreadPoolExecutor$
>  at
> {code}

This message was sent by Atlassian JIRA

View raw message