activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-591) Wrong XAException return code when broker timeout is hit
Date Fri, 12 Aug 2016 15:57:21 GMT

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

ASF GitHub Bot commented on ARTEMIS-591:
----------------------------------------

Github user clebertsuconic commented on the issue:

    https://github.com/apache/activemq-artemis/pull/595
  
    There's no way to determine here if the Rolledback was caused by a timed out.. or something
else (like an error or something).
    
    I had been involved on tests where I was dealing with errors during load. And I don't
see how to distinguish between an error and a time out.
    
    
    I'm also not sure what's the risk of


> Wrong XAException return code when broker timeout is hit
> --------------------------------------------------------
>
>                 Key: ARTEMIS-591
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-591
>             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}
> "[XA_RBTIMEOUT]
> 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
by:
> {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(ActiveMQSessionContext.java:346)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1115)
>  at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
>  at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
>  at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:897)
>  at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(TxConnectionListener.java:1063)
>  at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(TransactionSynchronizer.java:438)
>  at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(TransactionSynchronizer.java:376)
>  at
> org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:130)
>  at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
>  at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
>  at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
>  at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
>  at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
>  at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
>  at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
>  at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:71)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:498)
>  at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60)
>  at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135)
>  at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
>  at
> org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean$$$endpoint1.afterDelivery(Unknown
> Source)
>  at
> org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:321)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:932)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
>  at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1045)
>  at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
>  at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message