[JBoss JIRA] (JBTM-3153) Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3153?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3153:
-----------------------------------
Git Pull Request: https://github.com/jbosstm/narayana/pull/1457
> Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
> ----------------------------------------------------------------------------------------------------
>
> Key: JBTM-3153
> URL: https://issues.jboss.org/browse/JBTM-3153
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> There is a possible race condition at the test {{SipleIsolatedServers}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where {{while loop}} can be infinite as the counter never gets expected number of {{2}}.
> This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced {{java.lang.LinkageError}} on JDK11.
> (The exact reason for the linkage error is for further investigation. But the test should be fixed.)
> [1]
> {code}
> [RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
> Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
> at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
> at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
> at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
> at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> The stuck tread waits at
> {code}
> "main" #1 prio=5 os_prio=0 cpu=4031.25ms elapsed=61387.77s tid=0x000000422f702800 nid=0x25fc in Object.wait() [0x000000422eeae000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(java.base(a)11.0.2/Native Method)
> - waiting on <no object reference available>
> at com.arjuna.ats.jta.distributed.SimpleIsolatedServers.testSimultaneousRecover(SimpleIsolatedServers.java:307)
> - waiting to re-lock in wait() <0x0000000766d00038> (a com.arjuna.ats.jta.distributed.SimpleIsolatedServers$CompletionCountLock)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base(a)11.0.2/Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.2/NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.2/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.2/Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:294)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBTM-3153) Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3153?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Ondrej Chaloupka created pull request #1457 in GitHub
-----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
> ----------------------------------------------------------------------------------------------------
>
> Key: JBTM-3153
> URL: https://issues.jboss.org/browse/JBTM-3153
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> There is a possible race condition at the test {{SipleIsolatedServers}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where {{while loop}} can be infinite as the counter never gets expected number of {{2}}.
> This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced {{java.lang.LinkageError}} on JDK11.
> (The exact reason for the linkage error is for further investigation. But the test should be fixed.)
> [1]
> {code}
> [RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
> Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
> at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
> at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
> at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
> at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> The stuck tread waits at
> {code}
> "main" #1 prio=5 os_prio=0 cpu=4031.25ms elapsed=61387.77s tid=0x000000422f702800 nid=0x25fc in Object.wait() [0x000000422eeae000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(java.base(a)11.0.2/Native Method)
> - waiting on <no object reference available>
> at com.arjuna.ats.jta.distributed.SimpleIsolatedServers.testSimultaneousRecover(SimpleIsolatedServers.java:307)
> - waiting to re-lock in wait() <0x0000000766d00038> (a com.arjuna.ats.jta.distributed.SimpleIsolatedServers$CompletionCountLock)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base(a)11.0.2/Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.2/NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.2/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.2/Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:294)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBTM-3153) Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3153?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3153:
-----------------------------------
Description:
There is a possible race condition at the test {{SipleIsolatedServers}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where {{while loop}} can be infinite as the counter never gets expected number of {{2}}.
This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced {{java.lang.LinkageError}} on JDK11.
(The exact reason for the linkage error is for further investigation. But the test should be fixed.)
[1]
{code}
[RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
The stuck tread waits at
{code}
"main" #1 prio=5 os_prio=0 cpu=4031.25ms elapsed=61387.77s tid=0x000000422f702800 nid=0x25fc in Object.wait() [0x000000422eeae000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base(a)11.0.2/Native Method)
- waiting on <no object reference available>
at com.arjuna.ats.jta.distributed.SimpleIsolatedServers.testSimultaneousRecover(SimpleIsolatedServers.java:307)
- waiting to re-lock in wait() <0x0000000766d00038> (a com.arjuna.ats.jta.distributed.SimpleIsolatedServers$CompletionCountLock)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base(a)11.0.2/Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.2/NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.2/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.2/Method.java:566)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:294)
at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
{code}
was:
There is a possible race condition at the test {{SipleIsolatedServers}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where {{while loop}} can be infinite as the counter never gets expected number of {{2}}.
This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced {{java.lang.LinkageError}} on JDK11.
(The exact reason for the linkage error is for further investigation. But the test should be fixed.)
[1]
{code}
[RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
> Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
> ----------------------------------------------------------------------------------------------------
>
> Key: JBTM-3153
> URL: https://issues.jboss.org/browse/JBTM-3153
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> There is a possible race condition at the test {{SipleIsolatedServers}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where {{while loop}} can be infinite as the counter never gets expected number of {{2}}.
> This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced {{java.lang.LinkageError}} on JDK11.
> (The exact reason for the linkage error is for further investigation. But the test should be fixed.)
> [1]
> {code}
> [RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
> Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
> at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
> at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
> at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
> at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> The stuck tread waits at
> {code}
> "main" #1 prio=5 os_prio=0 cpu=4031.25ms elapsed=61387.77s tid=0x000000422f702800 nid=0x25fc in Object.wait() [0x000000422eeae000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(java.base(a)11.0.2/Native Method)
> - waiting on <no object reference available>
> at com.arjuna.ats.jta.distributed.SimpleIsolatedServers.testSimultaneousRecover(SimpleIsolatedServers.java:307)
> - waiting to re-lock in wait() <0x0000000766d00038> (a com.arjuna.ats.jta.distributed.SimpleIsolatedServers$CompletionCountLock)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base(a)11.0.2/Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.2/NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.2/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.2/Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:294)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBTM-3153) Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3153?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3153:
-----------------------------------
Description:
There is a possible race condition at the test {{SipleIsolatedServers}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where {{while loop}} can be infinite as the counter never gets expected number of {{2}}.
This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced {{java.lang.LinkageError}} on JDK11.
(The exact reason for the linkage error is for further investigation. But the test should be fixed.)
[1]
{code}
[RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
was:
There is a possible race condition at the test `SipleIsolatedServers` (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where `while loop` can be infinite as the counter never gets expected number of `2`.
This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced `java.lang.LinkageError` on JDK11.
(The exact reason for the linkage error is for further investigation. But the test should be fixed.)
[1]
```
[RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
at java.base/java.lang.Thread.run(Thread.java:834)
```
> Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
> ----------------------------------------------------------------------------------------------------
>
> Key: JBTM-3153
> URL: https://issues.jboss.org/browse/JBTM-3153
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Testing
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> There is a possible race condition at the test {{SipleIsolatedServers}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where {{while loop}} can be infinite as the counter never gets expected number of {{2}}.
> This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced {{java.lang.LinkageError}} on JDK11.
> (The exact reason for the linkage error is for further investigation. But the test should be fixed.)
> [1]
> {code}
> [RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
> Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
> at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
> at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
> at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
> at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
> at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBTM-3153) Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created JBTM-3153:
--------------------------------------
Summary: Possible race condition at jts integration test com.arjuna.ats.jta.distributed.SimpleIsolatedServers
Key: JBTM-3153
URL: https://issues.jboss.org/browse/JBTM-3153
Project: JBoss Transaction Manager
Issue Type: Bug
Components: Testing
Affects Versions: 5.9.5.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
There is a possible race condition at the test `SipleIsolatedServers` (https://github.com/jbosstm/narayana/blob/5.9.5.Final/ArjunaJTS/integratio...) where `while loop` can be infinite as the counter never gets expected number of `2`.
This can happen in case of the recovery fails with some unexpected exception/error. For example the CI experienced `java.lang.LinkageError` on JDK11.
(The exact reason for the linkage error is for further investigation. But the test should be fixed.)
[1]
```
[RecMan1000] ProxyXAResource (1000:2000) XA_RECOVER [XAResource.TMSTARTRSCAN]
Exception in thread "RecMan1000" java.lang.LinkageError: loader com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader @72503b19 (instance of com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader, child of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate class definition for com.arjuna.ats.internal.jta.transaction.arjunacore.jca.SubordinationManager.
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:877)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:125)
at com.arjuna.ats.jta.distributed.server.IsolatableServersClassLoader.loadClass(IsolatableServersClassLoader.java:103)
at com.arjuna.ats.jta.distributed.server.impl.RemoteServerImpl.recoverFor(RemoteServerImpl.java:111)
at com.arjuna.ats.jta.distributed.server.impl.ProxyXAResource.recover(ProxyXAResource.java:174)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:329)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getNewXAResource(XARecoveryModule.java:368)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.getNewXAResource(XAResourceRecord.java:1254)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:1005)
at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1120)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.restore_state(SubordinateAtomicAction.java:212)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:490)
at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:453)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.<init>(SubordinateAtomicAction.java:75)
at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.<init>(TransactionImple.java:71)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:124)
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52)
at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:493)
at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.scan(RecoveryManagerImple.java:138)
at com.arjuna.ats.arjuna.recovery.RecoveryManager.scan(RecoveryManager.java:161)
at com.arjuna.ats.jta.distributed.server.impl.ServerImpl.doRecoveryManagerScan(ServerImpl.java:197)
at com.arjuna.ats.jta.distributed.SimpleIsolatedServers$4.run(SimpleIsolatedServers.java:299)
at java.base/java.lang.Thread.run(Thread.java:834)
```
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBTM-3148) Remote JTA EJB transaction context propagation fails to correctly run 1PC
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3148:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
When a failure happens during 1PC running subordinate transaction on behalf the transaction ends with heuristic outcome.
> Remote JTA EJB transaction context propagation fails to correctly run 1PC
> -------------------------------------------------------------------------
>
> Key: JBTM-3148
> URL: https://issues.jboss.org/browse/JBTM-3148
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome.
> Consider:
> # first server calls a second server
> # the first server uses as the resource only the remote call to the second server
> # transaction context is propagated and used at the second server
> # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s)
> # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}}
> # the second server is called with one phase commit
> # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
> # prepare on database resource and JMS resource is run
> # commit runs on the database resource, then...
> # JVM crashes before JMS broker is committed
> # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)
> In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.
> The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
> https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301...
> Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443
> In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
> That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.
> One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
> The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBTM-3148) Remote JTA EJB transaction context propagation fails to correctly run 1PC
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3148:
-----------------------------------
Git Pull Request: https://github.com/jbosstm/narayana/pull/1452
> Remote JTA EJB transaction context propagation fails to correctly run 1PC
> -------------------------------------------------------------------------
>
> Key: JBTM-3148
> URL: https://issues.jboss.org/browse/JBTM-3148
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome.
> Consider:
> # first server calls a second server
> # the first server uses as the resource only the remote call to the second server
> # transaction context is propagated and used at the second server
> # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s)
> # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}}
> # the second server is called with one phase commit
> # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
> # prepare on database resource and JMS resource is run
> # commit runs on the database resource, then...
> # JVM crashes before JMS broker is committed
> # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)
> In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.
> The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
> https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301...
> Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443
> In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
> That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.
> One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
> The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
[JBoss JIRA] (JBTM-3138) XTS txbridge does not run commit when 1PC is used, prepared phase fails on crash recovery later
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3138?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3138:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> XTS txbridge does not run commit when 1PC is used, prepared phase fails on crash recovery later
> -----------------------------------------------------------------------------------------------
>
> Key: JBTM-3138
> URL: https://issues.jboss.org/browse/JBTM-3138
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: XTS
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Attachments: server.log, stacktrace.txt
>
>
> As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant.
> In scenario
> * WS call to the WFLY server
> * inbound bridge injects the JTA transactions as subordinate under the WS AT one
> * prepare is called and the 2PC phase finishes
> * commit phase starts and JVM crashes
> * restart of WFLY server
> * recovery is expected to commit the participants
> the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed.
> This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 12 months
