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

Gytis Trikleris (JIRA) issues at jboss.org
Thu Sep 18 05:28:02 EDT 2014


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

Gytis Trikleris commented on JBTM-2256:
---------------------------------------

Me and Tom went through the stack trace and the code and this was the only cause we could find.
However, I can confirm that not adding ExtendedXAResourceRecordMap to the record types map causes expiry scanner to throw java.lang.InstantiationException. It is because AbstractRecord class is used as a default type, if the requested type does not exist. And in such case Class.newInstance() call will always fail, since it is an abstract class.
Swapping places of those two lines assures that ExtendedXAResourceRecordMap is added to the record types map before expiry scanner is started.

On the other hand, the main reason of this pull request was to check if it doesn't cause our qa tests to fail. I will contact people who raised the bugzilla, to confirm that this issue is fixed, since they can reproduce the error without modifying the code.

> 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
(v6.3.1#6329)


More information about the jbossts-issues mailing list