1 Reply Latest reply on Dec 4, 2018 6:26 AM by Ondra Chaloupka

    XTS inbound bridge fails to commit during crash recovery

    Ondra Chaloupka Master



      I have a question as follow-up to the fix of of the issue [JBTM-3079] InboundBridge recovery aborts live transactions ([Pull Request #1387). I would like check this particularly with jhalliday if he has time to verify.


      When applying the patch I was curious why the testcase does not contain test for commit scenario - like this: inbount txbridge - adding commt crashrec test · ochaloup/narayana@d4ee0b8.

      The idea of the test is the same as in other scenarios. Which is in my understanding:

      • A test client is deployed on the WFLY
      • Testcase calls the client
      • The client starts JTA transaction
      • The client invokes Webservice call to the WFLY
      • The webservice did some work - in this case it enlists a mock TestXAResource in the business method
      • The call comes back to client which commits the transaction
      • The 2PC starts
      • The prepare phase passes (there is  BridgeDurableParticipant, BridgeVolatileParticipant and TestXAResource)
      • The commit phase starts and the JVM crashes
      • The recovery is expected to commit the transaction but the transaction is rolled-back


      I tried to investigate what's happening and it's the ATParticipantRecoveryModule runs ParticipantEngine during recovery

      Thread [Periodic Recovery] (Suspended)
      ParticipantEngine.recovery() line: 315
      ATParticipantRecoveryRecord.activate() line: 68
      XTSATRecoveryManagerImple.recoverParticipants() line: 219
      ATParticipantRecoveryModule.processParticipantsStatus() line: 265
      ATParticipantRecoveryModule.periodicWorkSecondPass() line: 137
      PeriodicRecovery.doWorkInternal() line: 816
      PeriodicRecovery.run() line: 382

      as the state is prepared there is executed the WS call narayana/ParticipantEngine.java at 5.9.0.Final · jbosstm/narayana · GitHub -> narayana/ParticipantEngine.java at 5.9.0.Final · jbosstm/narayana · GitHub  sendPrepared() which ends at the CoordinatorProcessorImpl#prepared. As there was no "activation" of the txn id for the CoordinatorProcessor there is found no coordinator narayana/CoordinatorProcessorImpl.java at 5.9.0.Final which ends for rollback narayana/CoordinatorProcessorImpl.java at 5.9.0.Final.


      It sounds like there is a missing  some activation for the txn bridge subordinate participant as for example the AT participant is "reactivated" for the CoordinatorProcessor in the restoreState with the id here - narayana/ParticipantStub.java at 5.9.0.Final. Or the reactivation should be done differently, eg. at the place where participant is loaded? Or do I have some test misuderstanding?