[jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2256: ------------------------------------- Hi Gytis, The way to reproduce the bug is to put a breakpoint here: https://github.com/Gytis/narayana/blob/4.17/ArjunaCore/arjuna/classes/com... If you do that and you have a scanner configured and that needs to create an abstract record of say type 172 (for example, as the ExpiredAssumedCompleteScanner in the linked BZ may need to), it will fail. This is a reproducer I have to verify it: https://github.com/tomjenkinson/narayana/compare/4.17...JBTM-2256 You need to add the breakpoint in RecoveryManagerImple after it has started the expiry scanner but before it loads the recovery modules (line 113 above). You can also add a breakpoint in the reproducer class on "AbstractRecord.create(172);" If you allow the AbstractRecord.create(172); before you release the RecoveryManagerImple you will see: {quote} java.lang.InstantiationException at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at com.arjuna.ats.arjuna.coordinator.AbstractRecord.create(AbstractRecord.java:446) at com.hp.mwtests.ts.jta.jts.recovery.RecoveryManagerUnitTest$1.scan(RecoveryManagerUnitTest.java:41) at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171) {quote} Swapping the lines does not allow this scenario to occur. I think you should add a comment into your fix to provide more details on this so it is not swapped back in the future. Tom -- This message was sent by Atlassian JIRA (v6.3.1#6329)