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

Tom Jenkinson (JIRA) issues at jboss.org
Fri Sep 19 10:26:03 EDT 2014

    [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004330#comment-13004330 ] 

Tom Jenkinson commented on JBTM-2256:

Implementing the fix will prevent us creating a byteman race condition test case for the issue as it will (assuming the correct recovery modules are configured) no longer be possible for the expiry scanner to start before the Implementationsx.java is loaded.

A comment in the code that explains the issue (i.e. ExpiredEntryMonitor.startUp(); _MUST_ be called after _periodicRecovery = new PeriodicRecovery(threaded, useListener); and provide more details on that) is the best thing to ensure its not reverted, plus Gytis should also cherry-pick the test I have written https://github.com/tomjenkinson/narayana/compare/4.17...JBTM-2256 during verification of the issue. Even though Byteman verification isn't possible, the test could still alert us if something were to change in this area in the future.

On the link I provided above you will see that I have added byteman to verify the failure without the fix. Once the fix is applied the test will hand as the race condition no longer exists so that specific commit should not be cherry-picked but the underlying test can be.

> Race condition between recovery manager initialization and expiry scanner
> -------------------------------------------------------------------------
>                 Key: JBTM-2256
>                 URL: https://issues.jboss.org/browse/JBTM-2256
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Transaction Core
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 4.17.23, 5.0.4
> In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem.
> Swapping these two actions should solve the problem.

This message was sent by Atlassian JIRA

More information about the jbossts-issues mailing list