April 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3306) Quickstart jca-and-tomcat with JDK11, missing some maven dependencies

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3306?page=com.atlassian.jira.plugin... ] Mayank Kunwar updated JBTM-3306: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Quickstart jca-and-tomcat with JDK11, missing some maven dependencies > --------------------------------------------------------------------- > > Key: JBTM-3306 > URL: https://issues.redhat.com/browse/JBTM-3306 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Mayank Kunwar > Assignee: Mayank Kunwar > Priority: Major > > While running Quickstart jca-and-tomcat with JDK11 end up throwing below exception: > com.github.fungal.spi.deployers.DeployException: Deployment jar:file:/home/user/.m2/repository/org/jboss/ironjacamar/ironjacamar-embedded/1.1.0.Beta5/ironjacamar-embedded-1.1.0.Beta5.jar!/stdio.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:123) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean JBossStdioService > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.lang.IllegalStateException: Already installed > at org.jboss.stdio.StdioContext.install(StdioContext.java:142) > at org.jboss.stdio.StdioService.start(StdioService.java:34) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:428) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.042 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3305) Quickstart transactionaldriver-standalone module throws an exception when build with JDK11

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3305?page=com.atlassian.jira.plugin... ] Mayank Kunwar updated JBTM-3305: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Quickstart transactionaldriver-standalone module throws an exception when build with JDK11 > ------------------------------------------------------------------------------------------ > > Key: JBTM-3305 > URL: https://issues.redhat.com/browse/JBTM-3305 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Mayank Kunwar > Assignee: Mayank Kunwar > Priority: Major > > When running Quickstart transactionaldriver-standalone on JDK11 with below command throws exception. > mvn clean install > java.io.IOException: Can not attach to current VM > at jdk.attach/sun.tools.attach.HotSpotVirtualMachine.<init>(HotSpotVirtualMachine.java:75) > at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:57) > at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) > at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) > at org.jboss.byteman.agent.install.Install.attach(Install.java:451) > at org.jboss.byteman.agent.install.Install.install(Install.java:161) > at org.jboss.byteman.agent.install.Install.install(Install.java:116) > at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.loadAgent(BMUnitConfigState.java:516) > at org.jboss.byteman.contrib.bmunit.BMUnitConfigState.pushConfigurationState(BMUnitConfigState.java:669) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:73) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3247: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Failed LRA records are reported but they not kept > ------------------------------------------------- > > Key: JBTM-3247 > URL: https://issues.redhat.com/browse/JBTM-3247 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store. > It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3122) jbosstm/quickstarts tests can't be run with jdk9+

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3122?page=com.atlassian.jira.plugin... ] Mayank Kunwar updated JBTM-3122: -------------------------------- Git Pull Request: https://github.com/jbosstm/quickstart/pull/283 (was: https://github.com/jbosstm/quickstart/pull/278) > jbosstm/quickstarts tests can't be run with jdk9+ > ------------------------------------------------- > > Key: JBTM-3122 > URL: https://issues.redhat.com/browse/JBTM-3122 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.9.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). > The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the {{arquillian.xml}}. > See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 > {code} > --add-exports=java.base/sun.nio.ch=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED > --add-modules=java.se > {code} > The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. > Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3132) Common parent maven module for Narayana quickstarts

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3132?page=com.atlassian.jira.plugin... ] Mayank Kunwar updated JBTM-3132: -------------------------------- Git Pull Request: https://github.com/jbosstm/quickstart/pull/283 (was: https://github.com/jbosstm/quickstart/pull/278) > Common parent maven module for Narayana quickstarts > --------------------------------------------------- > > Key: JBTM-3132 > URL: https://issues.redhat.com/browse/JBTM-3132 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Testing > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > It would be beneficial to create a common quickstart maven module. > My intention is to have a one place where we can define: > * common profiles could be defined (one of such profile is Arquillian JDK9+ which defines JVM arguments needed for smooth run of tests, see https://issues.jboss.org/projects/JBTM/issues/JBTM-3122) > * common properties like arquillian version. This has benefit that quickstarts will run faster on CI as there won't be multiple versions to be downloaded. > * common repositories like jboss one > * unified checkstyle definition for all the quickstarts would be coded in one way which makes them easier to read > The quickstarts were designed to be independent on each other. The task is not to unified them. The proposal is about creating a place where a common stuff can be placed to. Otherwise the same configuration needs to be copied to multiple places. Which is hard to maintain > Other projects, e.g. WildFly, use the same approach of common parent, see https://github.com/wildfly/quickstart/blob/master/app-client/pom.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3307) LRACoordinatorRecovery2TestCase regularly fails on CI

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3307?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Michael Musgrove created pull request #1614 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRACoordinatorRecovery2TestCase regularly fails on CI > ----------------------------------------------------- > > Key: JBTM-3307 > URL: https://issues.redhat.com/browse/JBTM-3307 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > The test regularly fails CI > [ERROR] testRecovery2(io.narayana.lra.coordinator.LRACoordinatorRecovery2TestCase) Time elapsed: 30.455 s <<< FAILURE! > java.lang.AssertionError: LRA with short timeout should not be active > presumably due to a timing issue (since I cannot reproduce it on my laptop). I will see if there is a way to make the test more robust. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3307) LRACoordinatorRecovery2TestCase regularly fails on CI

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3307?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3307: ---------------------------------------- I would recommend disabling this test until it is made more reliable. > LRACoordinatorRecovery2TestCase regularly fails on CI > ----------------------------------------------------- > > Key: JBTM-3307 > URL: https://issues.redhat.com/browse/JBTM-3307 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > The test regularly fails CI > [ERROR] testRecovery2(io.narayana.lra.coordinator.LRACoordinatorRecovery2TestCase) Time elapsed: 30.455 s <<< FAILURE! > java.lang.AssertionError: LRA with short timeout should not be active > presumably due to a timing issue (since I cannot reproduce it on my laptop). I will see if there is a way to make the test more robust. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3307) LRACoordinatorRecovery2TestCase regularly fails on CI

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3307?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3307: ----------------------------------- Priority: Blocker (was: Major) > LRACoordinatorRecovery2TestCase regularly fails on CI > ----------------------------------------------------- > > Key: JBTM-3307 > URL: https://issues.redhat.com/browse/JBTM-3307 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > The test regularly fails CI > [ERROR] testRecovery2(io.narayana.lra.coordinator.LRACoordinatorRecovery2TestCase) Time elapsed: 30.455 s <<< FAILURE! > java.lang.AssertionError: LRA with short timeout should not be active > presumably due to a timing issue (since I cannot reproduce it on my laptop). I will see if there is a way to make the test more robust. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3307) LRACoordinatorRecovery2TestCase regularly fails on CI

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3307: -------------------------------------- Summary: LRACoordinatorRecovery2TestCase regularly fails on CI Key: JBTM-3307 URL: https://issues.redhat.com/browse/JBTM-3307 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The test regularly fails CI [ERROR] testRecovery2(io.narayana.lra.coordinator.LRACoordinatorRecovery2TestCase) Time elapsed: 30.455 s <<< FAILURE! java.lang.AssertionError: LRA with short timeout should not be active presumably due to a timing issue (since I cannot reproduce it on my laptop). I will see if there is a way to make the test more robust. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3304) Performance comparison with Atomikos may loop forever

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3304?page=com.atlassian.jira.plugin... ] Mayank Kunwar reassigned JBTM-3304: ----------------------------------- Assignee: Mayank Kunwar > Performance comparison with Atomikos may loop forever > ----------------------------------------------------- > > Key: JBTM-3304 > URL: https://issues.redhat.com/browse/JBTM-3304 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > > We have occasionally (though not common) seen our performance comparison (with other open source TMs) job loop forever when Atomikos fails to enlist a resource (for example job http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-performance/4/). > The correct behaviour should be to catch the error and abort the JMH run for that particular comparison. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 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 April 2020