[
https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin....
]
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)