[JBoss JIRA] (JBTM-1383) LogStoreRecoveryTest hang
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1383?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1383:
-------------------------------------
Doesn't seem to reproduce if you just run the single test:
{code}
for i in {1..200}; do echo ITERATION $i; ./build.sh -f ArjunaCore/arjuna/pom.xml -Dtest=LogStoreRecoveryTest test ; [ $? = 0 ] || break; done
{code}
Trying running the suite in a loop:
{code}
for i in {1..200}; do echo ITERATION $i; ./build.sh -f ArjunaCore/arjuna/pom.xml test ; [ $? = 0 ] || break; done
{code}
> LogStoreRecoveryTest hang
> -------------------------
>
> Key: JBTM-1383
> URL: https://issues.jboss.org/browse/JBTM-1383
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 5.0.0.M2
> Reporter: Michael Musgrove
> Assignee: Paul Robinson
> Attachments: debug.25494
>
>
> http://172.17.131.2/job/jbossts-narayana-java6/123 job is stuck running LogStoreRecoveryTest
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1354) JCA recovery race condition
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1354:
-------------------------------------
Problem is normally there is just one recovery manager thread, in the case of JCA we can be invoked by a second thread
> JCA recovery race condition
> ---------------------------
>
> Key: JBTM-1354
> URL: https://issues.jboss.org/browse/JBTM-1354
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, JTA, Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.4, 5.0.0.M2
>
>
> Evidenced in SimpleIsolatedServers::testSimultaneousRecovery
> Basically XATerminatorImple -> SAA::activate() -> XAResourceRecord::restore_state() -> getNewXAResource() -> XARecoveryModule::getNewXAResource()
> At this point _xidScans may be none-null but still only partial from the first scan: periodicWorkSecondPass -> bottomUpRecovery -> resourceInitiatedRecoveryForRecoveryHelpers -> xaRecovery
> if (_xidScans == null)
> _xidScans = new Hashtable<XAResource,RecoveryXids>();
> What I am not sure of is whether we should synchronize bottomUpRecovery and getNewXAResource as that would stop this race condition. Gonna give that a whirl.
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1354) JCA recovery race condition
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reopened JBTM-1354:
---------------------------------
> JCA recovery race condition
> ---------------------------
>
> Key: JBTM-1354
> URL: https://issues.jboss.org/browse/JBTM-1354
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, JTA, Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.3, 5.0.0.M2
>
>
> Evidenced in SimpleIsolatedServers::testSimultaneousRecovery
> Basically XATerminatorImple -> SAA::activate() -> XAResourceRecord::restore_state() -> getNewXAResource() -> XARecoveryModule::getNewXAResource()
> At this point _xidScans may be none-null but still only partial from the first scan: periodicWorkSecondPass -> bottomUpRecovery -> resourceInitiatedRecoveryForRecoveryHelpers -> xaRecovery
> if (_xidScans == null)
> _xidScans = new Hashtable<XAResource,RecoveryXids>();
> What I am not sure of is whether we should synchronize bottomUpRecovery and getNewXAResource as that would stop this race condition. Gonna give that a whirl.
--
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
11 years, 11 months
[JBoss JIRA] (JBTM-1354) JCA recovery race condition
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1354?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1354:
--------------------------------
Fix Version/s: 4.17.4
(was: 4.17.3)
> JCA recovery race condition
> ---------------------------
>
> Key: JBTM-1354
> URL: https://issues.jboss.org/browse/JBTM-1354
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, JTA, Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.4, 5.0.0.M2
>
>
> Evidenced in SimpleIsolatedServers::testSimultaneousRecovery
> Basically XATerminatorImple -> SAA::activate() -> XAResourceRecord::restore_state() -> getNewXAResource() -> XARecoveryModule::getNewXAResource()
> At this point _xidScans may be none-null but still only partial from the first scan: periodicWorkSecondPass -> bottomUpRecovery -> resourceInitiatedRecoveryForRecoveryHelpers -> xaRecovery
> if (_xidScans == null)
> _xidScans = new Hashtable<XAResource,RecoveryXids>();
> What I am not sure of is whether we should synchronize bottomUpRecovery and getNewXAResource as that would stop this race condition. Gonna give that a whirl.
--
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
11 years, 11 months