August 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3147: ----------------------------------- Affects Version/s: 5.9.5.Final > WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3147 > URL: https://issues.jboss.org/browse/JBTM-3147 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.6.Final > > > When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. > This behaviour is confirmed by comments in the source code and tests expect such behaviour. > Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks > https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... > {quote} > // if prepare timed out then we return error so it goes back on the > // prepare list and is rolled back > {quote} > The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. > See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... > {quote} > // log an error here -- if the participant is dead it will retry anyway > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka closed JBTM-3147. ---------------------------------- > WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3147 > URL: https://issues.jboss.org/browse/JBTM-3147 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.6.Final > > > When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. > This behaviour is confirmed by comments in the source code and tests expect such behaviour. > Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks > https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... > {quote} > // if prepare timed out then we return error so it goes back on the > // prepare list and is rolled back > {quote} > The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. > See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... > {quote} > // log an error here -- if the participant is dead it will retry anyway > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3147: ----------------------------------- Fix Version/s: 5.9.6.Final (was: 5.9.5.Final) > WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3147 > URL: https://issues.jboss.org/browse/JBTM-3147 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.6.Final > > > When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. > This behaviour is confirmed by comments in the source code and tests expect such behaviour. > Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks > https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... > {quote} > // if prepare timed out then we return error so it goes back on the > // prepare list and is rolled back > {quote} > The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. > See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... > {quote} > // log an error here -- if the participant is dead it will retry anyway > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3150) Upgrade the version of maven that we use to build with and migrate from swarm to thorntail

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3150?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3150: ----------------------------------- Fix Version/s: 5.9.6.Final (was: 5.next) > Upgrade the version of maven that we use to build with and migrate from swarm to thorntail > ------------------------------------------------------------------------------------------ > > Key: JBTM-3150 > URL: https://issues.jboss.org/browse/JBTM-3150 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.6.Final > > > Narayana builds with version 3.3.9 of maven. This version is quite old and does not work with containers such as thorntail and quarkus. This JIRA is to upgrade our build to use version 3.6.1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3150) Upgrade the version of maven that we use to build with and migrate from swarm to thorntail

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3150?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka closed JBTM-3150. ---------------------------------- > Upgrade the version of maven that we use to build with and migrate from swarm to thorntail > ------------------------------------------------------------------------------------------ > > Key: JBTM-3150 > URL: https://issues.jboss.org/browse/JBTM-3150 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.6.Final > > > Narayana builds with version 3.3.9 of maven. This version is quite old and does not work with containers such as thorntail and quarkus. This JIRA is to upgrade our build to use version 3.6.1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 8 months

1
0
0 / 0

[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 reopened JBTM-3153: ------------------------------------ > 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 > Fix For: 5.9.6.Final > > > There is a possible race condition at the test {{SipleIsolatedServers#testSimultaneousRecover}} (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, 8 months

1
0
0 / 0

[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 closed JBTM-3153. ---------------------------------- Resolution: Done > 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 > Fix For: 5.9.6.Final > > > There is a possible race condition at the test {{SipleIsolatedServers#testSimultaneousRecover}} (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, 8 months

1
0
0 / 0

[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: ----------------------------------- Fix Version/s: 5.9.6.Final > 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 > Fix For: 5.9.6.Final > > > There is a possible race condition at the test {{SipleIsolatedServers#testSimultaneousRecover}} (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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3157) LRA participant does not respect JAX-RS path definitions

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3157?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka closed JBTM-3157. ---------------------------------- > LRA participant does not respect JAX-RS path definitions > -------------------------------------------------------- > > Key: JBTM-3157 > URL: https://issues.jboss.org/browse/JBTM-3157 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.9.6.Final > > > When LRA participant defines paths for participant methods like this: > {code:java} > @PUT > @Path("compensate") > @Compensate > public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { > System.out.println("Compensate: " + lraId); > } > {code} > instead of: > {code:java} > @PUT > @Path("/compensate") > @Compensate > public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { > System.out.println("Compensate: " + lraId); > } > {code} > The participant methods are never executed because the constructed URL is not valid. However, even the first code snippet is still a valid JAX-RS resource definition and thus it should be respected. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3154) CI failure: AS_TESTS compilation failure on JDK8 with duplicate duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3154?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3154: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.6.Final Resolution: Done > CI failure: AS_TESTS compilation failure on JDK8 with duplicate duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3154 > URL: https://issues.jboss.org/browse/JBTM-3154 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.6.Final > > > Running the CDI tests as > {code} > export JBOSS_HOME=... > ./tools/maven/bin/mvn -B -s "./tools/maven/conf/settings.xml" -Dbpa=centos54x64 test -f ./ArjunaJTA/cdi/pom.xml -B -Parq -Duse.valgrind=false > {code} > {code} > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/DelegatingTransactionManager.java:[49,17] duplicate class: com.arjuna.ats.jta.cdi.DelegatingTransactionManager > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/JTASupplier.java:[42,7] duplicate class: com.arjuna.ats.jta.cdi.JTASupplier > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorMandatory.java:[44,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/NarayanaTransactionManager.java:[70,1] duplicate class: com.arjuna.ats.jta.cdi.NarayanaTransactionManager > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorSupports.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorSupports > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/TransactionExtension.java:[56,8] duplicate class: com.arjuna.ats.jta.cdi.TransactionExtension > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorNever.java:[44,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorNever > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/TransactionScopeCleanup.java:[14,8] duplicate class: com.arjuna.ats.jta.cdi.TransactionScopeCleanup > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/TransactionContext.java:[52,8] duplicate class: com.arjuna.ats.jta.cdi.TransactionContext > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorNotSupported.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorNotSupported > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorRequired.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/NarayanaTransactionSynchronizationRegistry.java:[59,1] duplicate class: com.arjuna.ats.jta.cdi.NarayanaTransactionSynchronizationRegistry > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/DelegatingTransactionSynchronizationRegistry.java:[49,17] duplicate class: com.arjuna.ats.jta.cdi.DelegatingTransactionSynchronizationRegistry > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorRequiresNew.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequiresNew > [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorBase.java:[59,17] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2019