[jbossts-issues] [JBoss JIRA] (JBTM-2147) Transactions are leaked when XAResource misbehaves

[Tom Jenkinson (JIRA)]

    [ https://issues.jboss.org/browse/JBTM-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12960801#comment-12960801 ] 

Tom Jenkinson commented on JBTM-2147:
-------------------------------------

Hi,

Thanks for the report. Your latest comment is slightly different to your initial one, but it is now something I am happy to fix. Effectively you are saying the a cached reference to a transaction (such as the reaper has) can cause the afterCompletion of Synchronizations to be triggered if an XAResource throws RuntimeException out of end.

What I propose is to fix that specific issue, i.e. prevent afterCompletion being called on subsequent attempts to rollback the transaction if it is broken by the XAR. You are correct that that is a state machine issue in Narayana that subsequent calls to rollback should not trigger afterCompletion.

I won't make further changes to the transaction manager to handle RuntimeExceptions from XAR::end and say disassociate the transaction from the thread as this is not spec compliant so the resource is the thing that should be fixed for that.

Note, you will still get a single ARJUNA012078: Abort called illegaly on atomic action 0:ffff40bab98c:1f71a485:5335ece7:3625a31) in the log, but that would be expected in this scenario.

Thanks again for the report and I hope you concur with my approach,
Tom
                
> Transactions are leaked when XAResource misbehaves
> --------------------------------------------------
>
>                 Key: JBTM-2147
>                 URL: https://issues.jboss.org/browse/JBTM-2147
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS
>    Affects Versions: 4.17.7
>         Environment: jboss EAP 6.1.1
>            Reporter: Koen Janssens
>            Assignee: Tom Jenkinson
>
> We have noticed that arjuna leaks transactions when something 'unexpected' happens during tx aborting. The transaction stays in 'aborting' state while it does notify TxLIsteners that the tx has ended. 
> This can be reproduced as follows: 
> * A TX is started and both a DB (last)resource and horntq (XA) resource get enlisted. The tx takes a long time and times out. 
> * Arjuna reaper thread notices the time out and starts a worker thread to cancel the TX. 
> * Before the worker thread can 'abort' the hornetq XA resource, the arjuna worker thread is interruped (txReaperCancelWaitPeriod expires) by arjuna
> * Since the worker thread is interruped, the hornetq XA resource throws an 'HornetQInterruptedException'
> * This unexpected exception causes arjuna to notify registered javax/transaction/Synchronization's (and return DB connection to the pool), without ending the Tx. 
> From then on, jboss logs are full of: 
> Trying to start a new transaction when old is not complete: Old: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff40bab98c:1f71a485:5335ece7:3625a31, node_name=1, branch_uid=0:ffff40bab98c:1f71a485:5335ece7:3625bbc, subordinatenodename=null, eis_name=java:/XAOracleDS >, New < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff40bab98c:1f71a485:5335ece7:3641efc, node_name=1, branch_uid=0:ffff40bab98c:1f71a485:5335ece7:36420a1, subordinatenodename=null, eis_name=java:/XAOracleDS >, Flags 0
> Although the root cause is a misbehaving hornetq resource, I think arjuna should be a bit more resilient. 
> More background in https://access.redhat.com/support/cases/01061583/

--
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