[
https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin....
]
Tom Jenkinson commented on JBTM-2854:
-------------------------------------
There is a critical issue here but it's rather in the way WFTC is not attempting to
pass in the full Xid.
The reason I downgraded the JBTM to Major is that you have to pass us more data in the Xid
than the gtrid so even making a better error message it would be for something that should
not happen.
You have to pass us the Xid of the parent SubordinateTransaction for importing of the
propagated transaction so that when you call doRecover with the parent node name we can
give you the right set of transactions back.
You could think of the interface for importing transactions as:
importTransaction(byte[] gtrid, String parent)
The parent name for importing is part of the Xid in the propagator node and can be
determined before propagation using:
((com.arjuna.ats.jta.transaction.Transactio)
transactionManagerService.getTransactionManager().getTransaction()).getTxId(); // The
Javadoc is not clear, for subordinate transactions data is included in the Xid beyond the
gtrid
Note that passing a dummy bqual with zerod data would not fully work because of the reason
that we wouldn't be able to record the correct parent node name. This would mean in a
recovery situation the parent would need to be sure to directly scan all known servers -
reducing the opportunity to clean up partially completed transactions to when the root
coordinator was online. That might well work but it wasn't designed that way and so
lots of tests will fail (and the slower recovery I just mentioned). Recovery for EJB
remoting was designed to go A -> B -> C rather than A -> C.
XATerminatorImple.importTransaction can produce
ArrayIndexOutOfBoundsException
------------------------------------------------------------------------------
Key: JBTM-2854
URL:
https://issues.jboss.org/browse/JBTM-2854
Project: JBoss Transaction Manager
Issue Type: Bug
Components: JTA
Reporter: David Lloyd
Assignee: Michael Musgrove
Here is what the stack trace looks like:
{noformat}
Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32
at
com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:115)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:57)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105)
at
com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599)
at
org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585)
... 11 more
{noformat}
It appears that there is no protection against an XID of inadequate length in
XATxConverter#setSubordinateNodeName.
At present the protocol is attempting to import an XID which contains only the gtid from
the master node (based on what I discussed with [~tomjenkinson] some time ago at a
previous meeting). This can be changed if it is wrong, but either way this method should
fail with a friendlier exception if the XID is not valid for some reason.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)