June 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3042) API to get detailed LRA information should not include stats type data

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3042?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-3042. ---------------------------------- Resolution: Rejected Management and query APIs were removed from the LRA TCk/API (https://github.com/eclipse/microprofile-lra/issues/107). If they ever reappear in a later milestone then a new issue should be created. > API to get detailed LRA information should not include stats type data > ---------------------------------------------------------------------- > > Key: JBTM-3042 > URL: https://issues.jboss.org/browse/JBTM-3042 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The interface to obtain information about an LRA [1] includes data such as when the LRA was started and ended. This type of information is more appropriate to monitoring and statistics gathering rather than core LRA info. Not all implementations may want to / be able to report these accurately so perhaps move them to an extended optional interface > [1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-client/src/ma... -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3086) dependentLRA test failure

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3086?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-3086. ---------------------------------- Resolution: Out of Date This TCK test is no longer failing. > dependentLRA test failure > ------------------------- > > Key: JBTM-3086 > URL: https://issues.jboss.org/browse/JBTM-3086 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/...] in the microprofile-lra test suite fails if the [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/sr...] is set to true. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3090) LRA TCK failures need to report more context to facilitate debugging

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3090?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-3090. ---------------------------------- Resolution: Rejected The extra logging information is now present in the MP-LRA TCK so I am rejecting this issue. > LRA TCK failures need to report more context to facilitate debugging > -------------------------------------------------------------------- > > Key: JBTM-3090 > URL: https://issues.jboss.org/browse/JBTM-3090 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The TCK test failure message reports > > failures.forEach(f -> System.out.printf("%s%n", f)); > where f is the failure reason. There is also a verbose option which prints out the stack trace where the failure was reported. But in some failure cases these two pieces of information are insufficient to debug the failure. It would be nice if the resources that participated in the test also logged information which could be reported for more effective analysis of the reasons for the failure. This last requirement may affect the TCK itself so the code in the eclipse microprofile-lra repo should be analysed as well. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3051) LRA test timeLimit failure on JDK 9

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3051?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-3051. ---------------------------------- Resolution: Duplicate Issue This issue duplicates JBTM-3145 > LRA test timeLimit failure on JDK 9 > ----------------------------------- > > Key: JBTM-3051 > URL: https://issues.jboss.org/browse/JBTM-3051 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Whilst fixing issue JBTM-2942 I noticed that the test timeLimitRequiredLRA fails consistently with the reason: > {quote} > 2018-08-14 11:38:00,244 INFO [stdout] (pool-7-thread-1) testName.getMethodName(): WARNING: test did not close http://localhost:8080/lra-coordinator/0_ffff0a3f00d6_245c07ef_5b72b0d1_104 > {quote} > I have temporarily disabled the test in the TCK runner: > {quote} > rts/lra/lra-tck/tck/src/main/java/org/eclipse/microprofile/lra/tck/RunTck.java > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3065) Check that starting LRA's via CDI and API in the same method works

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3065?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3065: ----------------------------------- Fix Version/s: 6.later (was: 5.next) > Check that starting LRA's via CDI and API in the same method works > ------------------------------------------------------------------ > > Key: JBTM-3065 > URL: https://issues.jboss.org/browse/JBTM-3065 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 6.later > > > The LRA spec supports starting LRA's via a Java API or via Java annotations. If the two approaches are used together in the same resource method then the LRA started via the API should be nested inside the one started by an annotation. > If the annotated class also contains @Compensate and @Complete annotations (which means that the resource should join the outer LRA) and the resource method Joins the nested LRA then the resource should receive callbacks for both the outer and nested LRA's. > The following code shows an example: > {code} > @PUT > @LRA(LRA.Type.REQUIRES_NEW) // starts a new LRA on entry > public String doInTransaction() { > URL lraId = lraClient.startLRA(...); // starts a nested LRA > lraClient.join(...) // join the nested LRA > lraClient.closeLRA(lraId); // close the nested LRA > // assert that the nested callbacks were invoked > // assert that the callbacks for the outer LRA have not been called yet > } > {code} > Similar comments apply if the resource joins via the LRAManagement API: > {code} > @Inject > private LRAManagement lraManagement; > public String doInTransaction() { > lraManagement.joinLRA(this, lraId, 0L, TimeUnit.SECONDS); > // etc > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3018) Migrate the LRA implementation to use the microprofile-lra API

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3018?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3018: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Migrate the LRA implementation to use the microprofile-lra API > -------------------------------------------------------------- > > Key: JBTM-3018 > URL: https://issues.jboss.org/browse/JBTM-3018 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.8.2.Final > > > The LRA implementation should depend on the Eclipse microprofile-lra maven artifact for the API (https://github.com/jbosstm/microprofile-lra/tree/microprofile-lra/api). > Make sure the API bundled with narayana is deprecated. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3145) LRA TCK test failure on CI

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3145: ----------------------------------- Summary: LRA TCK test failure on CI (was: LRA TCK test failure on JDK11) > LRA TCK test failure on CI > -------------------------- > > Key: JBTM-3145 > URL: https://issues.jboss.org/browse/JBTM-3145 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j... > It is also failing consistently on JDK8 (after the the migration to thorntail) with: > [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3145) LRA TCK test failure on JDK11

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3145: ----------------------------------- Description: The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j... It is also failing consistently on JDK8 (after the the migration to thorntail) with: [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider was:The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/416/PROFILE=LRA,j... > LRA TCK test failure on JDK11 > ----------------------------- > > Key: JBTM-3145 > URL: https://issues.jboss.org/browse/JBTM-3145 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j... > It is also failing consistently on JDK8 (after the the migration to thorntail) with: > [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 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: ----------------------------------- Description: 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} 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} 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} > 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#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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3152) XTS over SSL Quickstart Failure

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3152?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka commented on JBTM-3152: ---------------------------------------- The reason which makes the quickstart to fail is error during quickstart compilation. The {{XTS/ssl}} quickstart uses deployment from https://github.com/wildfly/quickstart of project wsat-simple (deployment final name is {{wsat-simple.war}}). Because of some internal changes at CI - probably some update(?), use of an newer version of maven - suddenly compilation fails with [1]. The reason seems to be wrong configuration of the enforcer plugin in the {{jboss-parent}} bom. The issues is created at: https://github.com/jboss/jboss-parent-pom/issues/65 The workaround is to skip the enforcer rule to be used during the wildfly quickstarts compilation. [1] {code} Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce (enforce-java-version) on project wsat-simple: Unable to parse configuration of mojo org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce for parameter bannedRepositories: Cannot assign configuration entry 'bannedRepositories' with value 'http://*' of type java.lang.String to property of type java.util.List -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce (enforce-java-version) on project wsat-simple: Unable to parse configuration of mojo org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce for parameter bannedRepositories: Cannot assign configuration entry 'bannedRepositories' with value 'http://*' of type java.lang.String to property of type java.util.List at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:220) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to parse configuration of mojo org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce for parameter bannedRepositories: Cannot assign configuration entry 'bannedRepositories' with value 'http://*' of type java.lang.String to property of type java.util.List at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:607) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:539) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:119) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: org.codehaus.plexus.component.configurator.ComponentConfigurationException: Cannot assign configuration entry 'bannedRepositories' with value 'http://*' of type java.lang.String to property of type java.util.List at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.failIfNotTypeCompatible(AbstractConfigurationConverter.java:100) at org.codehaus.plexus.component.configurator.converters.composite.CollectionConverter.fromConfiguration(CollectionConverter.java:82) at org.eclipse.sisu.plexus.CompositeBeanHelper.convertProperty(CompositeBeanHelper.java:268) at org.eclipse.sisu.plexus.CompositeBeanHelper.setProperty(CompositeBeanHelper.java:210) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:101) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:57) at org.codehaus.plexus.component.configurator.converters.composite.AbstractCollectionConverter.fromChildren(AbstractCollectionConverter.java:54) at org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromConfiguration(ArrayConverter.java:52) at org.eclipse.sisu.plexus.CompositeBeanHelper.convertProperty(CompositeBeanHelper.java:273) at org.eclipse.sisu.plexus.CompositeBeanHelper.setProperty(CompositeBeanHelper.java:174) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:101) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:34) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:577) ... 22 more {code} > XTS over SSL Quickstart Failure > ------------------------------- > > Key: JBTM-3152 > URL: https://issues.jboss.org/browse/JBTM-3152 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.5.Final > > > CI job narayana-quickstarts XTS over SSL Quickstart is failing regularly because the server is not reporting 'Transaction succeeded!': > > Doing the test by requesting 'http://localhost:8180/WSATSimpleServletClient' > > + curl -X GET http://localhost:8180/WSATSimpleServletClient > > + grep 'Transaction succeeded!' > See for example build: > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/285/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 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 June 2019