[
https://issues.jboss.org/browse/JBTM-2147?page=com.atlassian.jira.plugin....
]
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