Uploaded image for project: 'JBoss Transaction Manager'
  1. JBoss Transaction Manager
  2. JBTM-3656

XTS test failure (TestBACrashDuringOnePhaseCommit.SingleCoordinatorCompletionParticipantCloseTest)

    XMLWordPrintable

Details

    • Bug
    • Resolution: Cannot Reproduce
    • Major
    • None
    • 5.12.7.Final
    • XTS
    • None

    Description

      [ERROR] Tests run: 3, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 705.711 s <<< FAILURE! - in com.arjuna.qa.junit.TestBACrashDuringOnePhaseCommit
      [ERROR] SingleCoordinatorCompletionParticipantCloseTest(com.arjuna.qa.junit.TestBACrashDuringOnePhaseCommit)  Time elapsed: 637.814 s  <<< ERROR!
      java.lang.RuntimeException: jboss-as was not killed by Byteman, this indicates a test failure
          at com.arjuna.qa.extension.BaseServerKillProcessor.kill(BaseServerKillProcessor.java:62)
          at org.jboss.arquillian.container.impl.ContainerImpl.kill(ContainerImpl.java:207)

       

          etc - see attached files for the log output which shows the test trying to start the XTSServiceTestRunner:

      ```

      [0m[0m23:32:48,025 INFO  [org.jboss.jbossts.xts.servicetests.bean.XTSServiceTestRunnerBean] (ServerService Thread Pool – 87) Starting XTSServiceTestRunner

      ```

      but the service never starts, ie there is no corresponding message like the following:

      ```

      [0m[0m23:43:11,281 INFO  [org.jboss.jbossts.xts.servicetests.bean.XTSServiceTestRunnerBean] (ServerService Thread Pool – 30) Started XTSServiceTestRunner

      ```

      See attached logs of a successful (115.log) versus an unsuccessful (116.log) run.

       

      Looking at the code it seems like there is a possibility that the initialisation of the recovery manager could be too slow, for example these lines could be made more resilient to slow ininitalisation:

       

       https://github.com/jbosstm/narayana/blob/a372a0a12dbd3d989005bb66a2e77de832a6fdb7/XTS/WS-T/dev/src/org/jboss/jbossts/xts/recovery/participant/ba/XTSBARecoveryManager.java#L24 or https://github.com/jbosstm/narayana/blob/a372a0a12dbd3d989005bb66a2e77de832a6fdb7/XTS/WS-T/dev/src/org/jboss/jbossts/xts/recovery/participant/at/XTSATRecoveryManager.java#L24 - they don't look very resilient - either that or https://github.com/jbosstm/narayana/blob/master/XTS/localjunit/xtstest/src/org/jboss/jbossts/xts/servicetests/service/recovery/TestBARecoveryModule.java#L42 and https://github.com/jbosstm/narayana/blob/master/XTS/localjunit/xtstest/src/org/jboss/jbossts/xts/servicetests/service/recovery/TestATRecoveryModule.java#L38 might want to add retry logic too rather than assuming null can't come back

      The same failure has been seen on both JDK 11 and JDK 17

      Attachments

        1. 115.log
          315 kB
        2. 116.log
          346 kB
        3. jstack.2313
          114 kB

        Issue Links

          Activity

            People

              rh-ee-msappegr Marco Sappe Griot
              rhn-engineering-mmusgrov Michael Musgrove
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: