Details
-
Bug
-
Resolution: Done
-
Critical
-
5.1.0.BETA4
-
None
Description
As shown in the attached log, different transactions running in separate threads are generating the same XID, in this particular case, XID with:
globalTransactionId: ByteArray{size=64, array=[-36, -4, 27, 111, 3, 49, 118, -49, 55, 74, 25, 12, 57, -96, 17, -119, -30, -113, 98, -42, -52, 49, 74,
93, 44, -94, 39, -71, -54, 37, 108, -102, -113, 82, 73, -88, 103, 88, -44, -49, -58, 127, -93, 83, 32, 124, 18, 83, 35, -116, -38, 43, -26, -87, 20, -82, -29,
36, -20, 50, 97, -18, -30, 80]}
branchQualifier = ByteArray{size=64, array=[-104, 118, -26, -26, -67, -13, -84, -71, -34, -99, -124, 111, -83, -71, 2, 97, -9, 40, 12, -108, -127, 9, -92,
-112, 1, 38, 99, 21, -126, 10, -36, 114, -26, 82, -74, 26, -14, -102, -8, -104, 55, -33, 109, 33, 97, -20, 51, 5, -122, -99, -17, -39, 59, -26, 124, -57, 6,
-47, -34, -35, -79, 15, -67, -12]}
In the log, we see both Stressor-0 and Stressor-1 using the same transaction. I've added some further logging because this sometimes leads (not shown in the logs) to spurious erros such as:
javax.transaction.xa.XAException at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:237) at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:230) at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:116) at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:302) at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:84)
These are the result of the local transaction not being found amongst the registered transactions. If multiple transactions are using the same XID, this can easily be explained.
Finally, in the attached log, the other worrying thing is:
2011-11-15 15:21:53,341 [pool-1-thread-1] WARN [org.infinispan.transaction.TransactionTable] ISPN000100: Stopping but there're transactions that did not finish in time: ....
Basically, those are transactions being leaked which sometimes lead to OOMEs when running Radargun (at least in optimistic locking). There're a fair few places in the code from which transactions can be removed transaction table and at the moment there's no logging there, so it's hard to say which of those removals should have happened.
I'm attaching logs, XML configs...etc and will move on to test with a proper transaction manager.
