[ https://issues.jboss.org/browse/JBTM-1611?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-1611: ---------------------------------------- There are two distinct error conditions here. CrashRecovery09 tests 1, 3 and 5 and CrashRecovery10 tests 1, 3 and 5 all fail for the same reason: There is code in ServerTopLevelAction.java which handles the incoming prepare call which eventually ends up in LockManager. The locking scheme used by LockManager depends upon whether or not there is a transaction associated. The fix is to ensure that ServerTopLevelAction does the thread association on prepare (note that this fix was added to the master branch back in May, see JBTM-1350, and that is why we don't see these failures there). CrashRecovery12 test 03 and 06 fail for a number of different reasons: To run with the hornetq store each task is started using ExecutionWrapper.java but using the wrapper to *explicitly* start the Recover Manager does not start it correctly (note that if the wrapper is used to start a different main class then the Recovery manager is started correctly). The particular tests work as follows: # start a recovery manager process # start a client which creates a recoverable object but crashes in phase 2 # start a third process which will accept the replay completion call So, for a successful outcome: * the recovery manager must be running; * the initial client and recovery manager must use the same object store (but the tests are configured to use stores in different locations on the disk); * the process fielding the replay completion call must be listening on the same socket that the recovery manager is using. The tests use port offsets for these two process so they end up using different sockets so recovery never completes. Resolving these 3 problems makes both tests pass. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira