[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