[JBoss JIRA] (JBTM-2287) JTS mode sends an erroneous xa_end to resource manager if prepare() returns RMFAIL
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2287?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2287:
--------------------------------
Fix Version/s: 4.17.26
> JTS mode sends an erroneous xa_end to resource manager if prepare() returns RMFAIL
> ----------------------------------------------------------------------------------
>
> Key: JBTM-2287
> URL: https://issues.jboss.org/browse/JBTM-2287
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 4.17.15
> Environment: EAP 6.2.4 with JBoss Transactions 4.17.15
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
> Fix For: 4.17.26, 5.0.4
>
>
> The scenario is as follows (and works fine with JTA, see below):
> Two XAResources in the same transaction, with xid1 and xid2, respectively.
> (For better readability, log file excerpts are referenced and provided at the end of the description.)
> start xid1
> start xid2
> end xid1, tmsuccess
> prepare xid1 -> XAException.XAER_RMFAIL; provoked, txn is indeed prepared in our test case
> end xid1, tmfail -> against XA protocol, however silently ignored by us
> [error1 printed in log file]
> end xid2, tmfail
> rollback xid2
> [error2 printed in log file]
> [JTS: periodic, but fruitless recovery attempts]
> as an effect, the transaction branch is never recovered and the dead transaction hangs around forever in the database; it looks like, as if the JTS recovery component forgot to early about that transaction, so does not do any rollback/commit decision for the reported to-be-recovered transaction
> with JTA the call sequence is as follows:
> start xid1
> start xid2
> end xid1, tmsuccess
> prepare xid1 -> XAException.XAER_RMFAIL; provoked, txn is indeed prepared in our test case
> rollback xid1 //this races with recovery module, but in any case, will be rolled back
> end xid2, tmfail
> rollback xid2
> [JTA: periodic, successfull recovery]
> With JTA, rollback might even be triggered twice (second invocation ignored by us)
> here the log file excerpts, Xids printed with own toString() impl, because of JBTM-2284)
> [JTA: periodic, successfull recovery]
> 10:48:20,646 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:48:20,646 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131077-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.113.21.-21.110.84.100.126.76.0.0.0.41.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.113.21.-21.110.84.100.126.76.0.0.0.42.0.0.0.0.0.0.0.0
> 10:48:23,689 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Rolled back xid < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a6a3229:7115eb6e:54647e4c:29, node_name=1, branch_uid=0:ffff0a6a3229:7115eb6e:54647e4c:2a, subordinatenodename=null, eis_name=unknown eis name >
> [JTS: periodic, but fruitless recovery attempts]
> 09:59:49,664 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 09:59:49,665 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 09:59:58,022 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 09:59:58,022 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:06,067 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:06,067 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:14,184 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:14,184 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:22,275 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:22,275 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:30,329 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:30,329 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:38,377 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:38,377 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:46,493 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:46,493 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:54,545 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:54,545 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> [error1]
> 09:59:46,904 WARN [com.arjuna.ats.jts] (EJB default - 4) ARJUNA022223: ExtendedResourceRecord.topLevelAbort caught exception: org.omg.CORBA.UNKNOWN: Server-side Exception: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_25]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_25]
> at org.jacorb.orb.SystemExceptionHelper.read(SystemExceptionHelper.java:223) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.jacorb.orb.ReplyReceiver.getReply(ReplyReceiver.java:319) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.jacorb.orb.Delegate.invoke_internal(Delegate.java:1090) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.jacorb.orb.Delegate.invoke(Delegate.java:957) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:80) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at com.arjuna.ArjunaOTS._ArjunaSubtranAwareResourceStub.rollback(_ArjunaSubtranAwareResourceStub.java:75)
> at com.arjuna.ats.internal.jts.resources.ExtendedResourceRecord.topLevelAbort(ExtendedResourceRecord.java:445)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2875)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2854)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1924)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1494)
> at com.arjuna.ats.internal.jts.orbspecific.coordinator.ArjunaTransactionImple.commit(ArjunaTransactionImple.java:375)
> at com.arjuna.ats.internal.jts.ControlWrapper.commit(ControlWrapper.java:243)
> at com.arjuna.ats.internal.jts.orbspecific.CurrentImple.commit(CurrentImple.java:247)
> at com.arjuna.ats.jts.extensions.AtomicTransaction.commit(AtomicTransaction.java:276)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.commitAndDisassociate(TransactionImple.java:1296)
> at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.commit(BaseTransaction.java:130)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) [jboss-as-ejb3-7.3.4.Final-redhat-1.jar:7.3.4.Final-redhat-1]
>
> [error2]
> 09:59:46,962 ERROR [stderr] (EJB default - 4) org.omg.CORBA.TRANSACTION_ROLLEDBACK
> 09:59:46,962 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jts.orbspecific.coordinator.ArjunaTransactionImple.commit(ArjunaTransactionImple.java:414)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jts.ControlWrapper.commit(ControlWrapper.java:243)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jts.orbspecific.CurrentImple.commit(CurrentImple.java:247)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.jts.extensions.AtomicTransaction.commit(AtomicTransaction.java:276)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.commitAndDisassociate(TransactionImple.java:1296)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.commit(BaseTransaction.java:130)
> 09:59:46,964 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 09:59:46,964 ERROR [stderr] (EJB default - 4) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-1431) LastResourceRecord.shouldAdd allows insertion regardless of order and type info
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1431?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1431:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1001909|https://bugzilla.redhat.com/show_bug.cgi?id=1001909] from POST to ON_QA
> LastResourceRecord.shouldAdd allows insertion regardless of order and type info
> -------------------------------------------------------------------------------
>
> Key: JBTM-1431
> URL: https://issues.jboss.org/browse/JBTM-1431
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Transaction Core
> Affects Versions: 4.17.3
> Reporter: Mark Little
> Assignee: Mark Little
> Fix For: 4.17.9, 5.0.0.M2
>
>
> So looking at the code, LastResource is meant to be ordered last in the intentions list (check topLevelPrepare to see this). However, a quick look at the code in LastResourceRecord shows that there is a bug:
> public boolean shouldAdd (AbstractRecord a)
> {
> if (a.typeIs() == typeIs())
> {
> if (ALLOW_MULTIPLE_LAST_RESOURCES) {
> if (!_disableMLRWarning
> || (_disableMLRWarning && !_issuedWarning)) {
> tsLogger.i18NLogger.warn_lastResource_multipleWarning(a.toString());
> _issuedWarning = true;
> }
> return true;
> }
> else {
> tsLogger.i18NLogger.warn_lastResource_disallow(this.toString(), a.toString());
> return false;
> }
> }
> else
> {
> return true; <------- Here is the bug!
> }
> }
> Basically if the record to be added is not a LastResourceRecord then it gets added immediately, ignoring any further checks on type, order etc. This is wrong.
> And looking back at the code from 6 years ago we see that this was much simpler:
> public boolean shouldAdd (AbstractRecord a)
> {
> return (a.typeIs() == typeIs()) ;
> }
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-1867) Confusing error logged after crash recovery on prepare when hornetq object store used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1867?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1867:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 992915|https://bugzilla.redhat.com/show_bug.cgi?id=992915] from POST to ON_QA
> Confusing error logged after crash recovery on prepare when hornetq object store used
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1867
> URL: https://issues.jboss.org/browse/JBTM-1867
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 4.17.7, 5.0.0.M3
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Fix For: 4.17.9, 5.0.0.M5
>
>
> There is logged an confusing error after crash recovery happens when server crashed in prepare phase.
> {code}
> 14:47:59,697 ERROR [stderr] (RequestProcessor-10) com.arjuna.ats.arjuna.exceptions.ObjectStoreException: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:153)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.remove_committed(HornetqObjectStoreAdaptor.java:186)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.destroyState(XAResourceRecord.java:1271)
> 14:47:59,699 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=TestXAResourceRecovered(TestXAResourceCommon(0, null)))
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.rollback(XAResourceRecord.java:411)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ArjunaOTS.OTSAbstractRecordPOA._invoke(OTSAbstractRecordPOA.java:213)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) Caused by: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:904)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalBase.appendDeleteRecord(JournalBase.java:163)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:82)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:151)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) ... 7 more
> {code}
> This happens when hornetq object store is used. This is caused because of the rollback is called on resource two times. This is ok - this matches to OTS spec (https://bugzilla.redhat.com/show_bug.cgi?id=988724).
> But after the second call of rollback the TM tries to remove Xid from object store. But as the xid does not exist anymore the hornetq object store implementation throws exception that is logged directly on stderr:
> XAResourceRecord.destroyState does e.printStackTrace()
> I would propose to put this exception to debug or trace as it does not mean error in fact.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-2242:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1133346|https://bugzilla.redhat.com/show_bug.cgi?id=1133346] from POST to ON_QA
> Misbehaving XAResources may delay deployments
> ---------------------------------------------
>
> Key: JBTM-2242
> URL: https://issues.jboss.org/browse/JBTM-2242
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Application Server Integration
> Affects Versions: 4.17.22, 5.0.2
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 4.17.23, 5.0.4
>
>
> Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers:
> XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-2255:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1080035|https://bugzilla.redhat.com/show_bug.cgi?id=1080035] from POST to ON_QA
> Do not return StatusCommiting, if transaction was commited by the original transaction manager
> ----------------------------------------------------------------------------------------------
>
> Key: JBTM-2255
> URL: https://issues.jboss.org/browse/JBTM-2255
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 4.17.23, 5.0.4
>
>
> We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing.
> However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-2256:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1104584|https://bugzilla.redhat.com/show_bug.cgi?id=1104584] from POST to ON_QA
> 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.8#6338)
11 years, 4 months