[
https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin....
]
Tom Jenkinson commented on JBTM-2735:
-------------------------------------
I created a pull on JBTM-2701
https://github.com/jbosstm/narayana/pull/1060 - it seems to
make your test pass too.
However, I think there is an issue with the test which I fixed as follows.
{quote}
[tom@wicket eap-tests-transactions](master)(14:51:41) $ git diff
jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java
diff --git
a/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java
b/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java
index e20407e..9aa6dfc 100644
---
a/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java
+++
b/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java
@@ -581,7 +581,7 @@ public class JcaInflowTransactionTestCase extends TestBaseOneServer {
* <b>TODO:</b> it's expected this test will need to be tuned after
discussion on raised jira
*/
@Test
- @Ignore("JBEAP-5641/JBTM-2735: EIS can't finish all participants of inflow
in-doubt transaction after jvm crash")
+// @Ignore("JBEAP-5641/JBTM-2735: EIS can't finish all participants of inflow
in-doubt transaction after jvm crash")
public void jvmCrashAfterPrepare() throws Throwable {
JBossLogParserSetup.addSkipPatternForTest(".*XAER_RMFAIL.*",
".*javax.transaction.xa.XAException.*");
@@ -620,16 +620,16 @@ public class JcaInflowTransactionTestCase extends TestBaseOneServer
{
// I think yes, as for EIS the transaction managed by app server TM is in fact
one participant
Assert.assertEquals("One xid should be returned", "1",
numberOfXids.get());
- doRecovery();
+// doRecovery();
// the participant was recovered -> it's in prepare state - let's
commit it
sendCommit(xidNumId);
// xa resource should be committed
- instrumentedTestXAResource.assertKnownInstances(2);
+ instrumentedTestXAResource.assertKnownInstances(1);
instrumentedTestXAResource.assertMethodNotCalled("rollback");
instrumentedTestXAResource.assertMethodNotCalled("prepare");
- instrumentedTestXAResource.assertMethodCallCount("Both two TestXAResources
should be committed", "commit", 1);
+ instrumentedTestXAResource.assertMethodCallCount("Both two TestXAResources
should be committed", "commit", 2);
// and logs should be empty (even jboss cli should say so)
TMOperations ops =
ManagementClientSetup.getTMOperations(TestProperties.CRASHREC_CONTAINER);
{quote}
EIS can't finish all participants of inflow in-doubt transaction
after jvm crash
--------------------------------------------------------------------------------
Key: JBTM-2735
URL:
https://issues.jboss.org/browse/JBTM-2735
Project: JBoss Transaction Manager
Issue Type: Bug
Components: JTA, JTS
Affects Versions: 5.3.3.Final
Reporter: Ondra Chaloupka
Assignee: Tom Jenkinson
Priority: Critical
Fix For: 5.next
When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is
crashed at the start of commit phase then EIS can't recover all transaction
participants.
Expected flow of the case would be
# enlist two participants of inflow transaction - that means TM manages subordinate
transaction and accepts orders from EIS RAR
# TM receives commit order by EIS RAR call {{XATerminator.commit}}
# TM prepares both participants
# end phase prepares, start phase commits
# JVM crashes
# app server is restarted again
# EIS system repeats commit call as subordinate txn was not finished
# TM calls commit on both participants to finish the transaction
This scenario has two troubles in current implementation
If app server is restarted (after jvm crash happened) and EIS calls commit right after
the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
For the commit have got a real effect on in-doubt transaciton there needs to be called
recovery first. From that point in time the in-doubt inflow transaction is
"available" for EIS RAR XATerminator.commit call. But there is another issue.
Transaction was stopped with two participants prepared. But after commit is called from
XATerminator only one XAResource is committed. The other one is left and forgotten. As the
transaction itself is resolved as finished (thus removed from log store) there is no way
to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
(_The reason could be that both XA resources shared the xid, as discussed in other place,
TM does not rights to change xid and it needs to reuse existing one provided by EIS to all
the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)