From issues at jboss.org Tue Sep 1 05:26:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 1 Sep 2015 05:26:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2468) xts, jts and rts performance comparison job has failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2468 started by Gytis Trikleris. --------------------------------------------- > xts, jts and rts performance comparison job has failures > -------------------------------------------------------- > > Key: JBTM-2468 > URL: https://issues.jboss.org/browse/JBTM-2468 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > > The weekly NCL jenkins job for performance comparison of jts/xts/rts has three issues: > - the throughput is coming out at 0 (I think it is because its very slow but it needs investigating); > - the jts component fails to configure wildfly into jts mode (I have temporarily disabled it in the job config); > - it runs against 9.0.0.Alpha2-SNAPSHOT (so it needs updating to run against the wildfly bi weekly builds) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 10:42:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 1 Sep 2015 10:42:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2468) xts, jts and rts performance comparison job has failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2468: ---------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jbosstm/performance/pull/20 Raised PR to update from jacorb to iiop-openjdk subsystem. Also, reverted commit with the profile to download WildFly, since that added unnecessary dependency. CI now downloads WildFly nightly build, thus is always up to date. > xts, jts and rts performance comparison job has failures > -------------------------------------------------------- > > Key: JBTM-2468 > URL: https://issues.jboss.org/browse/JBTM-2468 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > > The weekly NCL jenkins job for performance comparison of jts/xts/rts has three issues: > - the throughput is coming out at 0 (I think it is because its very slow but it needs investigating); > - the jts component fails to configure wildfly into jts mode (I have temporarily disabled it in the job config); > - it runs against 9.0.0.Alpha2-SNAPSHOT (so it needs updating to run against the wildfly bi weekly builds) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 10:49:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 1 Sep 2015 10:49:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2501) Remove quickstart dependency on WildFly version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2501: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove quickstart dependency on WildFly version > ----------------------------------------------- > > Key: JBTM-2501 > URL: https://issues.jboss.org/browse/JBTM-2501 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > Currently quickstarts use org.wildfly group to get managed and remote containers. This imposes dependency on the specific WildFly version. org.wildfly.arquillian had separate versioning from WildFly, thus it is easier to keep up. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Sep 1 11:32:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 1 Sep 2015 11:32:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2502) Raw XTS quickstart failure In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2502: ------------------------------------- Summary: Raw XTS quickstart failure Key: JBTM-2502 URL: https://issues.jboss.org/browse/JBTM-2502 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator, XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Blocker Fix For: 5.next Raw XTS quickstart test gets SOAPFaultException in every build. {code} ------------------------------------------------------------------------------- Test set: org.jboss.jbossts.xts.demotest.XTSDemoTest ------------------------------------------------------------------------------- Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 21.14 sec <<< FAILURE! testBusinessActivity(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 3 sec <<< FAILURE! java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) at org.jboss.jbossts.xts.demotest.XTSDemoTest.testBusinessActivity(XTSDemoTest.java:101) 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:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) 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:497) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) testAtomicTransaction(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 0.297 sec <<< FAILURE! java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) at org.jboss.jbossts.xts.demotest.XTSDemoTest.testAtomicTransaction(XTSDemoTest.java:96) 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:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) 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:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) 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:497) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 02:56:05 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 2 Sep 2015 02:56:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2503) The deprecated api in the wildfly-blacktie has been removed in the wildfly-core In-Reply-To: References: Message-ID: Amos Feng created JBTM-2503: ------------------------------- Summary: The deprecated api in the wildfly-blacktie has been removed in the wildfly-core Key: JBTM-2503 URL: https://issues.jboss.org/browse/JBTM-2503 Project: JBoss Transaction Manager Issue Type: Bug Components: Application Server Integration, BlackTie Reporter: Amos Feng Assignee: Amos Feng It looks like the deprecated api has been removed in the wildfly-core upgrading to 2.0.0.Beta5. http://albany.eng.hst.ams2.redhat.com/job/narayana-catelyn/989/console http://albany.eng.hst.ams2.redhat.com/job/narayana/922/ {code} Caused by: java.lang.NoSuchMethodError: org.jboss.as.controller.registry.ManagementResourceRegistration.registerOperationHandler(Ljava/lang/String;Lorg/jboss/as/controller/OperationStepHandler;Lorg/jboss/as/controller/descriptions/DescriptionProvider;ZLorg/jboss/as/controller/registry/OperationEntry$EntryType;)V at org.wildfly.extension.blacktie.BlacktieSubsystemExtension.initialize(BlacktieSubsystemExtension.java:80) at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final] {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 02:56:06 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 2 Sep 2015 02:56:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2503) The deprecated api in the wildfly-blacktie has been removed in the wildfly-core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2503: ---------------------------- Priority: Critical (was: Major) > The deprecated api in the wildfly-blacktie has been removed in the wildfly-core > -------------------------------------------------------------------------------- > > Key: JBTM-2503 > URL: https://issues.jboss.org/browse/JBTM-2503 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > > It looks like the deprecated api has been removed in the wildfly-core upgrading to 2.0.0.Beta5. > http://albany.eng.hst.ams2.redhat.com/job/narayana-catelyn/989/console > http://albany.eng.hst.ams2.redhat.com/job/narayana/922/ > {code} > Caused by: java.lang.NoSuchMethodError: org.jboss.as.controller.registry.ManagementResourceRegistration.registerOperationHandler(Ljava/lang/String;Lorg/jboss/as/controller/OperationStepHandler;Lorg/jboss/as/controller/descriptions/DescriptionProvider;ZLorg/jboss/as/controller/registry/OperationEntry$EntryType;)V > at org.wildfly.extension.blacktie.BlacktieSubsystemExtension.initialize(BlacktieSubsystemExtension.java:80) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final] > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 06:53:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 2 Sep 2015 06:53:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2502) Raw XTS quickstart failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2502: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/150 > Raw XTS quickstart failure > -------------------------- > > Key: JBTM-2502 > URL: https://issues.jboss.org/browse/JBTM-2502 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > Raw XTS quickstart test gets SOAPFaultException in every build. > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.jbossts.xts.demotest.XTSDemoTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 21.14 sec <<< FAILURE! > testBusinessActivity(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 3 sec <<< FAILURE! > java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testBusinessActivity(XTSDemoTest.java:101) > 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:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > 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:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > testAtomicTransaction(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 0.297 sec <<< FAILURE! > java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testAtomicTransaction(XTSDemoTest.java:96) > 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:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > 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:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 06:56:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 2 Sep 2015 06:56:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2468) xts, jts and rts performance comparison job has failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2468: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > xts, jts and rts performance comparison job has failures > -------------------------------------------------------- > > Key: JBTM-2468 > URL: https://issues.jboss.org/browse/JBTM-2468 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > > The weekly NCL jenkins job for performance comparison of jts/xts/rts has three issues: > - the throughput is coming out at 0 (I think it is because its very slow but it needs investigating); > - the jts component fails to configure wildfly into jts mode (I have temporarily disabled it in the job config); > - it runs against 9.0.0.Alpha2-SNAPSHOT (so it needs updating to run against the wildfly bi weekly builds) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 06:57:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 2 Sep 2015 06:57:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2468) xts, jts and rts performance comparison job has failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104491#comment-13104491 ] Gytis Trikleris commented on JBTM-2468: --------------------------------------- I'm closing this issue and will extract throughput investigation to the separate one. > xts, jts and rts performance comparison job has failures > -------------------------------------------------------- > > Key: JBTM-2468 > URL: https://issues.jboss.org/browse/JBTM-2468 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > > The weekly NCL jenkins job for performance comparison of jts/xts/rts has three issues: > - the throughput is coming out at 0 (I think it is because its very slow but it needs investigating); > - the jts component fails to configure wildfly into jts mode (I have temporarily disabled it in the job config); > - it runs against 9.0.0.Alpha2-SNAPSHOT (so it needs updating to run against the wildfly bi weekly builds) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 06:59:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 2 Sep 2015 06:59:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2504) Investigate why throughput of JTS performance comparison test is 0 In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2504: ------------------------------------- Summary: Investigate why throughput of JTS performance comparison test is 0 Key: JBTM-2504 URL: https://issues.jboss.org/browse/JBTM-2504 Project: JBoss Transaction Manager Issue Type: Task Components: Performance Testing Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next We need to investigate why throughput of JTS performance comparison test is coming out at 0 ([~mmusgrov] thinks it is because it`s very slow); -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 09:31:05 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 2 Sep 2015 09:31:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2502) Raw XTS quickstart failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2502: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Raw XTS quickstart failure > -------------------------- > > Key: JBTM-2502 > URL: https://issues.jboss.org/browse/JBTM-2502 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > Raw XTS quickstart test gets SOAPFaultException in every build. > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.jbossts.xts.demotest.XTSDemoTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 21.14 sec <<< FAILURE! > testBusinessActivity(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 3 sec <<< FAILURE! > java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testBusinessActivity(XTSDemoTest.java:101) > 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:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > 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:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > testAtomicTransaction(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 0.297 sec <<< FAILURE! > java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testAtomicTransaction(XTSDemoTest.java:96) > 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:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > 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:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 11:00:08 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 2 Sep 2015 11:00:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2503) The deprecated api in the wildfly-blacktie has been removed in the wildfly-core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2503: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/905 > The deprecated api in the wildfly-blacktie has been removed in the wildfly-core > -------------------------------------------------------------------------------- > > Key: JBTM-2503 > URL: https://issues.jboss.org/browse/JBTM-2503 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > > It looks like the deprecated api has been removed in the wildfly-core upgrading to 2.0.0.Beta5. > http://albany.eng.hst.ams2.redhat.com/job/narayana-catelyn/989/console > http://albany.eng.hst.ams2.redhat.com/job/narayana/922/ > {code} > Caused by: java.lang.NoSuchMethodError: org.jboss.as.controller.registry.ManagementResourceRegistration.registerOperationHandler(Ljava/lang/String;Lorg/jboss/as/controller/OperationStepHandler;Lorg/jboss/as/controller/descriptions/DescriptionProvider;ZLorg/jboss/as/controller/registry/OperationEntry$EntryType;)V > at org.wildfly.extension.blacktie.BlacktieSubsystemExtension.initialize(BlacktieSubsystemExtension.java:80) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final] > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Sep 4 05:27:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 4 Sep 2015 05:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2505: ------------------------------------- Summary: Java heap space issue on Brandon Key: JBTM-2505 URL: https://issues.jboss.org/browse/JBTM-2505 Project: JBoss Transaction Manager Issue Type: Bug Components: Configuration Reporter: Gytis Trikleris Assignee: Tom Jenkinson Fix For: 5.next narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 4 05:43:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Sep 2015 05:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105507#comment-13105507 ] Tom Jenkinson commented on JBTM-2505: ------------------------------------- Is it new? I don't recall this happening before? > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 4 08:29:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 4 Sep 2015 08:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105573#comment-13105573 ] Gytis Trikleris commented on JBTM-2505: --------------------------------------- I don't remember it either. But so far I saw two failures on Brandon and one successful build on Janei in between the failures. > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 7 08:21:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 7 Sep 2015 08:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2503) The deprecated api in the wildfly-blacktie has been removed in the wildfly-core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2503: ---------------------------- Fix Version/s: 5.next > The deprecated api in the wildfly-blacktie has been removed in the wildfly-core > -------------------------------------------------------------------------------- > > Key: JBTM-2503 > URL: https://issues.jboss.org/browse/JBTM-2503 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.next > > > It looks like the deprecated api has been removed in the wildfly-core upgrading to 2.0.0.Beta5. > http://albany.eng.hst.ams2.redhat.com/job/narayana-catelyn/989/console > http://albany.eng.hst.ams2.redhat.com/job/narayana/922/ > {code} > Caused by: java.lang.NoSuchMethodError: org.jboss.as.controller.registry.ManagementResourceRegistration.registerOperationHandler(Ljava/lang/String;Lorg/jboss/as/controller/OperationStepHandler;Lorg/jboss/as/controller/descriptions/DescriptionProvider;ZLorg/jboss/as/controller/registry/OperationEntry$EntryType;)V > at org.wildfly.extension.blacktie.BlacktieSubsystemExtension.initialize(BlacktieSubsystemExtension.java:80) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 7 08:21:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 7 Sep 2015 08:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2503) The deprecated api in the wildfly-blacktie has been removed in the wildfly-core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2503: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > The deprecated api in the wildfly-blacktie has been removed in the wildfly-core > -------------------------------------------------------------------------------- > > Key: JBTM-2503 > URL: https://issues.jboss.org/browse/JBTM-2503 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.next > > > It looks like the deprecated api has been removed in the wildfly-core upgrading to 2.0.0.Beta5. > http://albany.eng.hst.ams2.redhat.com/job/narayana-catelyn/989/console > http://albany.eng.hst.ams2.redhat.com/job/narayana/922/ > {code} > Caused by: java.lang.NoSuchMethodError: org.jboss.as.controller.registry.ManagementResourceRegistration.registerOperationHandler(Ljava/lang/String;Lorg/jboss/as/controller/OperationStepHandler;Lorg/jboss/as/controller/descriptions/DescriptionProvider;ZLorg/jboss/as/controller/registry/OperationEntry$EntryType;)V > at org.wildfly.extension.blacktie.BlacktieSubsystemExtension.initialize(BlacktieSubsystemExtension.java:80) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 05:21:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 8 Sep 2015 05:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2506) BlackTie quickstarts fail to deploy In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2506: ------------------------------------- Summary: BlackTie quickstarts fail to deploy Key: JBTM-2506 URL: https://issues.jboss.org/browse/JBTM-2506 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie, Demonstrator Reporter: Gytis Trikleris Assignee: Amos Feng Fix For: 5.next {code} [exec] [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:deploy (default-cli) on project blacktie-quickstarts-integration1-ejb-ear: Could not execute goal deploy on /home/hudson/workspace/narayana-quickstarts/blacktie/integration1/ejb/ear/target/blacktie-quickstarts-integration1-ejb-ear-5.2.3.Final-SNAPSHOT.ear. Reason: I/O Error could not execute operation '{ [exec] [ERROR] "operation" => "read-attribute", [exec] [ERROR] "address" => [], [exec] [ERROR] "name" => "launch-type" [exec] [ERROR] }': java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed: For now upgrade responses must have a content length of zero. {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 05:27:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 8 Sep 2015 05:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2507) XTS qa test failures on IBM JDK In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2507: ------------------------------------- Summary: XTS qa test failures on IBM JDK Key: JBTM-2507 URL: https://issues.jboss.org/browse/JBTM-2507 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next {code} Running com.arjuna.qa.junit.TestBACrashDuringCommit Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2,179.93 sec <<< FAILURE! MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(com.arjuna.qa.junit.TestBACrashDuringCommit) Time elapsed: 672.338 sec <<< ERROR! java.lang.RuntimeException: jboss-as was not killed by Byteman, this indicates a test failure at com.arjuna.qa.extension.BaseServerKillProcessor.kill(BaseServerKillProcessor.java:62) at org.jboss.arquillian.container.impl.ContainerImpl.kill(ContainerImpl.java:235) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:193) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:187) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.killContainer(ContainerLifecycleController.java:186) at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.kill(ClientContainerController.java:230) at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:209) at com.arjuna.qa.junit.TestBACrashDuringCommit.MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(TestBACrashDuringCommit.java:24) {code} {code} Running com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 184.27 sec <<< FAILURE! subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.212 sec <<< ERROR! org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:158) at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:110) at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150) at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:213) at com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringPrepare.java:17) subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.243 sec <<< FAILURE! java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) 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.RunAfters.evaluate(RunAfters.java:33) at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createAfterContext(ContainerEventController.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter.update(UpdateTestResultBeforeAfter.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:122) at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) 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.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:507) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 07:18:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 8 Sep 2015 07:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2508) Cannot enable logging in the qa test suite In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2508: -------------------------------------- Summary: Cannot enable logging in the qa test suite Key: JBTM-2508 URL: https://issues.jboss.org/browse/JBTM-2508 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.2.2 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next narayana uses jboss logging which requires an actual logging implementation (such as log4j or slf4j) on the classpath. Our distribution does not ship any default implementation so it is not possible to enable logging in our qa tests (which rely on the distribution). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 09:10:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 8 Sep 2015 09:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2507) XTS qa test failures on IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reassigned JBTM-2507: ------------------------------------- Assignee: Michael Musgrove (was: Gytis Trikleris) > XTS qa test failures on IBM JDK > ------------------------------- > > Key: JBTM-2507 > URL: https://issues.jboss.org/browse/JBTM-2507 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > Running com.arjuna.qa.junit.TestBACrashDuringCommit > Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2,179.93 sec <<< FAILURE! > MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(com.arjuna.qa.junit.TestBACrashDuringCommit) Time elapsed: 672.338 sec <<< ERROR! > java.lang.RuntimeException: jboss-as was not killed by Byteman, this indicates a test failure > at com.arjuna.qa.extension.BaseServerKillProcessor.kill(BaseServerKillProcessor.java:62) > at org.jboss.arquillian.container.impl.ContainerImpl.kill(ContainerImpl.java:235) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:193) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:187) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.killContainer(ContainerLifecycleController.java:186) > at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.kill(ClientContainerController.java:230) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:209) > at com.arjuna.qa.junit.TestBACrashDuringCommit.MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(TestBACrashDuringCommit.java:24) > {code} > {code} > Running com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare > Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 184.27 sec <<< FAILURE! > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.212 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:158) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:110) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:213) > at com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringPrepare.java:17) > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.243 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:172) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createAfterContext(ContainerEventController.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter.update(UpdateTestResultBeforeAfter.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:122) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > 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.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 09:17:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 8 Sep 2015 09:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Artemis Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1854: -------------------------------- Summary: Artemis Journal failures in CI test suite on JDKORB (was: Hornetq failures in CI test suite on JDKORB) > Artemis Journal failures in CI test suite on JDKORB > --------------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 09:17:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 8 Sep 2015 09:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1854: -------------------------------- Summary: Journal failures in CI test suite on JDKORB (was: Artemis Journal failures in CI test suite on JDKORB) > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 09:28:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 8 Sep 2015 09:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2499) Race condition between BlackTie subsystem and Artemis starting up In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2499: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Race condition between BlackTie subsystem and Artemis starting up > ----------------------------------------------------------------- > > Key: JBTM-2499 > URL: https://issues.jboss.org/browse/JBTM-2499 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Occasionally TcpServer tries to lookup ConnectionFactory before Artemis has started that component. > Solution is to delay the lookup until the subsystem is accessed which should work and at least will not bork the TcpServer thread and fail the entire subsystem until reboot. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 11:27:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 8 Sep 2015 11:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2506) BlackTie quickstarts fail to deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2506: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/151 > BlackTie quickstarts fail to deploy > ----------------------------------- > > Key: JBTM-2506 > URL: https://issues.jboss.org/browse/JBTM-2506 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.next > > > {code} > [exec] [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:deploy (default-cli) on project blacktie-quickstarts-integration1-ejb-ear: Could not execute goal deploy on /home/hudson/workspace/narayana-quickstarts/blacktie/integration1/ejb/ear/target/blacktie-quickstarts-integration1-ejb-ear-5.2.3.Final-SNAPSHOT.ear. Reason: I/O Error could not execute operation '{ > [exec] [ERROR] "operation" => "read-attribute", > [exec] [ERROR] "address" => [], > [exec] [ERROR] "name" => "launch-type" > [exec] [ERROR] }': java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed: For now upgrade responses must have a content length of zero. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 12:10:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 8 Sep 2015 12:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2508) Cannot enable logging in the qa test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2508. ------------------------------------ Resolution: Done I have added a jdk logging.properties via the narayana.sh script whenever qa trace is enabled in narayana.sh > Cannot enable logging in the qa test suite > ------------------------------------------ > > Key: JBTM-2508 > URL: https://issues.jboss.org/browse/JBTM-2508 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > narayana uses jboss logging which requires an actual logging implementation (such as log4j or slf4j) on the classpath. Our distribution does not ship any default implementation so it is not possible to enable logging in our qa tests (which rely on the distribution). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 8 12:38:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 8 Sep 2015 12:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2509) Failing narayana-benchmarks CI jobs are not marked as failed In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2509: -------------------------------------- Summary: Failing narayana-benchmarks CI jobs are not marked as failed Key: JBTM-2509 URL: https://issues.jboss.org/browse/JBTM-2509 Project: JBoss Transaction Manager Issue Type: Bug Components: Performance Testing Affects Versions: 5.2.2 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next For example the CI job http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/33/ failed running the REST-AT benchmark but the run was marked as passed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 10 01:14:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 10 Sep 2015 01:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2506) BlackTie quickstarts fail to deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2506: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > BlackTie quickstarts fail to deploy > ----------------------------------- > > Key: JBTM-2506 > URL: https://issues.jboss.org/browse/JBTM-2506 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.next > > > {code} > [exec] [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:deploy (default-cli) on project blacktie-quickstarts-integration1-ejb-ear: Could not execute goal deploy on /home/hudson/workspace/narayana-quickstarts/blacktie/integration1/ejb/ear/target/blacktie-quickstarts-integration1-ejb-ear-5.2.3.Final-SNAPSHOT.ear. Reason: I/O Error could not execute operation '{ > [exec] [ERROR] "operation" => "read-attribute", > [exec] [ERROR] "address" => [], > [exec] [ERROR] "name" => "launch-type" > [exec] [ERROR] }': java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed: For now upgrade responses must have a content length of zero. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 11 03:15:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 11 Sep 2015 03:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2510) Provide some example jbossts-properties.xml on the narayana.io site In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2510: ----------------------------------- Summary: Provide some example jbossts-properties.xml on the narayana.io site Key: JBTM-2510 URL: https://issues.jboss.org/browse/JBTM-2510 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Release Process Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Minor Fix For: 5.next This will mean we don't need to download the zip to use them (for say maven users). We should provide: local JTA jacorb JTS JDKORB JTS IBMORB JTS -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 11 11:57:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 11 Sep 2015 11:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2509) Failing narayana-benchmarks CI jobs are not marked as failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2509: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/performance/pull/22 > Failing narayana-benchmarks CI jobs are not marked as failed > ------------------------------------------------------------- > > Key: JBTM-2509 > URL: https://issues.jboss.org/browse/JBTM-2509 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > For example the CI job http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/33/ failed running the REST-AT benchmark but the run was marked as passed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 11 11:57:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 11 Sep 2015 11:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2509) Failing narayana-benchmarks CI jobs are not marked as failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2509: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Failing narayana-benchmarks CI jobs are not marked as failed > ------------------------------------------------------------- > > Key: JBTM-2509 > URL: https://issues.jboss.org/browse/JBTM-2509 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > For example the CI job http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/33/ failed running the REST-AT benchmark but the run was marked as passed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 14 10:35:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Sep 2015 10:35:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2507) XTS qa test failures on IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2507: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/910 > XTS qa test failures on IBM JDK > ------------------------------- > > Key: JBTM-2507 > URL: https://issues.jboss.org/browse/JBTM-2507 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > Running com.arjuna.qa.junit.TestBACrashDuringCommit > Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2,179.93 sec <<< FAILURE! > MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(com.arjuna.qa.junit.TestBACrashDuringCommit) Time elapsed: 672.338 sec <<< ERROR! > java.lang.RuntimeException: jboss-as was not killed by Byteman, this indicates a test failure > at com.arjuna.qa.extension.BaseServerKillProcessor.kill(BaseServerKillProcessor.java:62) > at org.jboss.arquillian.container.impl.ContainerImpl.kill(ContainerImpl.java:235) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:193) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:187) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.killContainer(ContainerLifecycleController.java:186) > at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.kill(ClientContainerController.java:230) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:209) > at com.arjuna.qa.junit.TestBACrashDuringCommit.MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(TestBACrashDuringCommit.java:24) > {code} > {code} > Running com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare > Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 184.27 sec <<< FAILURE! > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.212 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:158) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:110) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:213) > at com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringPrepare.java:17) > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.243 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:172) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createAfterContext(ContainerEventController.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter.update(UpdateTestResultBeforeAfter.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:122) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > 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.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 14 10:40:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Sep 2015 10:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2507) XTS qa test failures on IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108323#comment-13108323 ] Michael Musgrove commented on JBTM-2507: ---------------------------------------- I created profile in XTS/localjunit/crash-recovery-tests/pom.xml that skips tests if the java.vendor environment variable is IBM. Note that we also have have a similar profile called ibmorb that is activated via a systrem property (called ibmorb-enabled). For consistency we should change the activation mechanism to use the java.vendor environment variable. > XTS qa test failures on IBM JDK > ------------------------------- > > Key: JBTM-2507 > URL: https://issues.jboss.org/browse/JBTM-2507 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > Running com.arjuna.qa.junit.TestBACrashDuringCommit > Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2,179.93 sec <<< FAILURE! > MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(com.arjuna.qa.junit.TestBACrashDuringCommit) Time elapsed: 672.338 sec <<< ERROR! > java.lang.RuntimeException: jboss-as was not killed by Byteman, this indicates a test failure > at com.arjuna.qa.extension.BaseServerKillProcessor.kill(BaseServerKillProcessor.java:62) > at org.jboss.arquillian.container.impl.ContainerImpl.kill(ContainerImpl.java:235) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:193) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:187) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.killContainer(ContainerLifecycleController.java:186) > at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.kill(ClientContainerController.java:230) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:209) > at com.arjuna.qa.junit.TestBACrashDuringCommit.MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(TestBACrashDuringCommit.java:24) > {code} > {code} > Running com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare > Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 184.27 sec <<< FAILURE! > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.212 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:158) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:110) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:213) > at com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringPrepare.java:17) > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.243 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:172) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createAfterContext(ContainerEventController.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter.update(UpdateTestResultBeforeAfter.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:122) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > 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.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 14 10:40:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Sep 2015 10:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2507) XTS qa test failures on IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2507: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > XTS qa test failures on IBM JDK > ------------------------------- > > Key: JBTM-2507 > URL: https://issues.jboss.org/browse/JBTM-2507 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > Running com.arjuna.qa.junit.TestBACrashDuringCommit > Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2,179.93 sec <<< FAILURE! > MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(com.arjuna.qa.junit.TestBACrashDuringCommit) Time elapsed: 672.338 sec <<< ERROR! > java.lang.RuntimeException: jboss-as was not killed by Byteman, this indicates a test failure > at com.arjuna.qa.extension.BaseServerKillProcessor.kill(BaseServerKillProcessor.java:62) > at org.jboss.arquillian.container.impl.ContainerImpl.kill(ContainerImpl.java:235) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:193) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:187) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.killContainer(ContainerLifecycleController.java:186) > at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.kill(ClientContainerController.java:230) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:209) > at com.arjuna.qa.junit.TestBACrashDuringCommit.MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(TestBACrashDuringCommit.java:24) > {code} > {code} > Running com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare > Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 184.27 sec <<< FAILURE! > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.212 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:158) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:110) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:213) > at com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringPrepare.java:17) > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.243 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:172) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createAfterContext(ContainerEventController.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter.update(UpdateTestResultBeforeAfter.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:122) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > 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.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:44:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1451) Transactional cloud resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1451: -------------------------------- Labels: available student (was: student) > Transactional cloud resources > ----------------------------- > > Key: JBTM-1451 > URL: https://issues.jboss.org/browse/JBTM-1451 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Student project > Reporter: jhalli > Labels: available, student > > Student project that we are not currently offering: > {quote} > Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution. > In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager. > This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:44:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1965) Add support for XADisk In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1965: -------------------------------- Labels: available (was: ) > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Student project > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > Labels: available, student > > We're unlikely to maintain fileio but there may be a need for supporting some transactional file interactions. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:44:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1965) Add support for XADisk In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1965: -------------------------------- Labels: available student (was: available) > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Student project > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > Labels: available, student > > We're unlikely to maintain fileio but there may be a need for supporting some transactional file interactions. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:45:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1449) Transactions in the browser In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1449: -------------------------------- Component/s: (was: Student project) > Transactions in the browser > --------------------------- > > Key: JBTM-1449 > URL: https://issues.jboss.org/browse/JBTM-1449 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: jhalli > Labels: student > > Student project that we are not currently offering: > {quote} > Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions. > To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. The work will be open source. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:45:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1450) Transaction processing in javascript In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1450: -------------------------------- Component/s: (was: Student project) > Transaction processing in javascript > ------------------------------------ > > Key: JBTM-1450 > URL: https://issues.jboss.org/browse/JBTM-1450 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: jhalli > Labels: student > > Student project that we are not currently offering: > {quote} > Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications. > This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:45:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1451) Transactional cloud resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1451: -------------------------------- Component/s: (was: Student project) > Transactional cloud resources > ----------------------------- > > Key: JBTM-1451 > URL: https://issues.jboss.org/browse/JBTM-1451 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: jhalli > Labels: available, student > > Student project that we are not currently offering: > {quote} > Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution. > In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager. > This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:45:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1965) Add support for XADisk In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1965: -------------------------------- Component/s: Resource Manager (was: Student project) > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > Labels: available, student > > We're unlikely to maintain fileio but there may be a need for supporting some transactional file interactions. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:47:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 05:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1451) Transactional cloud resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1451: -------------------------------- Description: Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution. In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager. This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source. was: Student project that we are not currently offering: {quote} Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution. In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager. This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source. {quote} > Transactional cloud resources > ----------------------------- > > Key: JBTM-1451 > URL: https://issues.jboss.org/browse/JBTM-1451 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: jhalli > Labels: available, student > > Many cloud based data storage systems, including the menagerie of NoSQL databases that are currently evolving, lack any significant transaction management capability and universally reject the formerly ubiquitous XA standard for classic 2PC ACID transactions. Whilst there are sound reasons for concluding that ACID transactions are not appropriate in such context, this nonetheless leaves a significant shortfall in capabilities compared to mature SQL based storage solutions. As a result, users are forced to roll their own transaction solutions in the business logic layer, an undesirable situation that cries out for a storage vendor or middleware based solution. > In this project you will examine the transaction handling needs of business systems operating on very large quantities of data, compare it with the capabilities provided by the new generation of storage systems used for handling such quantities, and provide solutions to bridge the gap. This may include investigating e.g. the scope for new transaction management standards and APIs that are appropriate or adaptable to more than one storage system; the use of non-ACID transaction models such as compensations; the interoperability issues that arise in an environment that encompasses not only multiple client and server languages (vis. CORBA) but also multiple transports (REST, thrift, ...); the extension of an existing NoSQL solution with additional transaction capabilities, or the provision of equivalent functionality by integration with 3rd party tools e.g. a distributed lock manager. > This project will require a good understanding of Java and optionally one or more additional languages if you wish to extend a storage system built in a non-Java language. Note that languages targeting the JVM are preferred. You should also have a basic understanding of the NoSQL movement and cloud computing concepts such as elasticity. Some knowledge of relevant concepts such as the CAP theorem and BASE model are preferable but not essential. The work will be open source. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 05:59:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 15 Sep 2015 05:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2511) Benchmark failure testing REST-AT with undertow In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2511: -------------------------------------- Summary: Benchmark failure testing REST-AT with undertow Key: JBTM-2511 URL: https://issues.jboss.org/browse/JBTM-2511 Project: JBoss Transaction Manager Issue Type: Bug Components: Performance Testing, REST Affects Versions: 5.2.2 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The REST-AT benchmark tests are failing: http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/37/ and the failure is: bq. Caused by: javax.ws.rs.ServiceUnavailableException: HTTP 503 Service Unavailable whilst sending a request to a JAX-RS service. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 06:00:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 06:00:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1450) Transaction processing in javascript In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1450: -------------------------------- Description: Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications. This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source. was: Student project that we are not currently offering: {quote} Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications. This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source. {quote} > Transaction processing in javascript > ------------------------------------ > > Key: JBTM-1450 > URL: https://issues.jboss.org/browse/JBTM-1450 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: jhalli > Labels: student > > Increasingly sophisticated applications are being implemented using the javascript language. Initially popular for browser based environments, the language is also gaining traction on the server side (NodeJS, etc). A single threaded model promotes use of callbacks and asynchronous I/O operations. Ongoing standardization work is starting to provide APIs for enterprise functionality (commonJS, IndexedDB, etc). The Rhino javascript engine allows javascript to run on any JVM. These factors lead to situations where distributed business applications may be written wholly or partially in javascript and may need to interact with existing business logic or services implemented in Java. In this project you will consider how to provide transaction management capabilities to such applications. > This project will require a good knowledge of javascript programming, ideally encompassing a server side javascript environment. Candidates should also possess some knowledge of Java and transaction concepts. The work will be open source. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 06:00:04 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 06:00:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1449) Transactions in the browser In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1449: -------------------------------- Description: Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions. To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. The work will be open source. was: Student project that we are not currently offering: {quote} Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions. To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. The work will be open source. {quote} > Transactions in the browser > --------------------------- > > Key: JBTM-1449 > URL: https://issues.jboss.org/browse/JBTM-1449 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: jhalli > Labels: student > > Recent developments in web standards (HTML5, specifically Web Storage a.k.a. DOM Storage) indicates a move towards widespread availability of client (i.e. web browser) side persistent storage accessible by web applications. Initially useful for making content and applications available offline, this also open up the possibility of object replication between client and server. In this project you will explore the applicability of transaction concepts to applications built on this model. In particular, you will focus on identifying and exploiting new opportunities made available by the existence of persistent storage on the browser, a vital pre-requisite for recoverable transactions. > To undertake this project you should have a strong interest in web based applications, some javascript programming experience and a basic understanding of transactions concepts. Previous experience of at least one javascript framework would be an advantage. The work will be open source. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 06:09:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 06:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1965) Add support for XADisk In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1965: -------------------------------- Description: Transactions are often used to structure activities within reliable software applications. In Java EE, business logic typically involves accessing transactional resource managers (databases, message queues) within boundaries denoted by calls to the JTA (begin/commit/rollback). The resource managers work with the transaction manager to perform e.g. locking, logging and recovery transparently to the application programmer. However, this separation of concerns is broken with regard to one important resource: the file system. Java's file I/O library does not support transactions, a situation which requires application programmers to implement such support manually in their programs. In this project you will develop a transaction aware resource manager for file I/O in Java. This library will provide application programmers with access to a filesystem that offers ACID semantics. We already have a transactional file I/O implementation but there are now alternatives available. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. Part of the work will be to compare and contrast the options available. To undertake this project you should have a good understanding of Java file I/O and some knowledge of transactions (ACID semantics and the JTA). The work will be open source. was:We're unlikely to maintain fileio but there may be a need for supporting some transactional file interactions. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > Labels: available, student > > Transactions are often used to structure activities within reliable software applications. In Java EE, business logic typically involves accessing transactional resource managers (databases, message queues) within boundaries denoted by calls to the JTA (begin/commit/rollback). The resource managers work with the transaction manager to perform e.g. locking, logging and recovery transparently to the application programmer. However, this separation of concerns is broken with regard to one important resource: the file system. Java's file I/O library does not support transactions, a situation which requires application programmers to implement such support manually in their programs. In this project you will develop a transaction aware resource manager for file I/O in Java. This library will provide application programmers with access to a filesystem that offers ACID semantics. > We already have a transactional file I/O implementation but there are now alternatives available. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. Part of the work will be to compare and contrast the options available. > To undertake this project you should have a good understanding of Java file I/O and some knowledge of transactions (ACID semantics and the JTA). The work will be open source. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 06:19:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 15 Sep 2015 06:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2512) Include BlackTie javadoc on Narayana.io In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2512: ----------------------------------- Summary: Include BlackTie javadoc on Narayana.io Key: JBTM-2512 URL: https://issues.jboss.org/browse/JBTM-2512 Project: JBoss Transaction Manager Issue Type: Task Components: Release Process Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 09:14:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 15 Sep 2015 09:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2513) Put build to undocumented, if it has anything other that JIRA id in description In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2513: ---------------------------------- Component/s: CI Report Generator > Put build to undocumented, if it has anything other that JIRA id in description > ------------------------------------------------------------------------------- > > Key: JBTM-2513 > URL: https://issues.jboss.org/browse/JBTM-2513 > Project: JBoss Transaction Manager > Issue Type: Task > Components: CI Report Generator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 09:14:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 15 Sep 2015 09:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2513) Put build to undocumented, if it has anything other that JIRA id in description In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2513: ------------------------------------- Summary: Put build to undocumented, if it has anything other that JIRA id in description Key: JBTM-2513 URL: https://issues.jboss.org/browse/JBTM-2513 Project: JBoss Transaction Manager Issue Type: Task Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 09:30:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 15 Sep 2015 09:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-1854: ---------------------------------- Steps to Reproduce: Use this branch of Narayana https://github.com/gytis/narayana/commits/master-JBTM-1854-hornetq-jdkorb-qa-failure. export WORKSPACE=$NARAYANA_HOME export QA_PROFILE="-Dprofile=hornetq" export QA_TRACE=1 export QA_TESTGROUP=jtsremote export QA_TESTMETHODS=JTSRemote_ImplicitPropagationTest export NARAYANA_VERSION=5.2.3.Final-SNAPSHOT export PROFILE=QA_JTS_JDKORB ./scripts/hudson/narayana.sh > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 09:31:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 15 Sep 2015 09:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2481) Automate NRP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108710#comment-13108710 ] Gytis Trikleris commented on JBTM-2481: --------------------------------------- I've added JIRA update script by my work branch: https://github.com/gytis/narayana/blob/master-JBTM-2481-Automate-NRP/scripts/release/update_jira.py > Automate NRP > ------------ > > Key: JBTM-2481 > URL: https://issues.jboss.org/browse/JBTM-2481 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > There are a number of steps on NRP that could be automated using Jira API. > Lets try to do that: > https://community.jboss.org/wiki/NarayanaReleaseProcess -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 16:57:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 16:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski reopened JBTM-2423: ---------------------------------- > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 16:57:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 16:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski reassigned JBTM-2423: ------------------------------------ Assignee: Tomasz Adamski (was: Michael Musgrove) > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 17:09:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 15 Sep 2015 17:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109002#comment-13109002 ] Michael Musgrove commented on JBTM-2423: ---------------------------------------- [~tomekadamski] please will you add a comment explaining why you have reopened this JIRA > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 17:31:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 17:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109011#comment-13109011 ] Tomasz Adamski commented on JBTM-2423: -------------------------------------- The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes about destruction of POA and shutdown of ORB were remove from ORBRunner class and: // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); code was added to ORBs shutdown method. The problem is that noone calls shutdown method too as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 17:32:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 17:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109011#comment-13109011 ] Tomasz Adamski edited comment on JBTM-2423 at 9/15/15 5:31 PM: --------------------------------------------------------------- The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes about destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method too as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). was (Author: tomekadamski): The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes about destruction of POA and shutdown of ORB were remove from ORBRunner class and: // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); code was added to ORBs shutdown method. The problem is that noone calls shutdown method too as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 17:32:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 17:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109011#comment-13109011 ] Tomasz Adamski edited comment on JBTM-2423 at 9/15/15 5:31 PM: --------------------------------------------------------------- The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes above destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method too as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). was (Author: tomekadamski): The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes about destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method too as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 17:33:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 17:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109011#comment-13109011 ] Tomasz Adamski edited comment on JBTM-2423 at 9/15/15 5:32 PM: --------------------------------------------------------------- The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes above destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method neither as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). was (Author: tomekadamski): The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes above destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method too as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 17:33:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 17:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109011#comment-13109011 ] Tomasz Adamski edited comment on JBTM-2423 at 9/15/15 5:32 PM: --------------------------------------------------------------- The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes above destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method neither as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving in the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). was (Author: tomekadamski): The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes above destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method neither as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving at the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 15 17:34:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 15 Sep 2015 17:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109011#comment-13109011 ] Tomasz Adamski edited comment on JBTM-2423 at 9/15/15 5:33 PM: --------------------------------------------------------------- The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes above destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method neither as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving in the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now so we can discuss it - will test it and paste it in few minutes if it passes the tests (and tomorrow if it doesn't :) ). was (Author: tomekadamski): The issue returned in WFLY-5261. I was looking at the problem today. The problem is that shutdown hooks are not executed - among them is JavaIdlRCShutdown - lack of is execution causes the error in WFLY-5261. In the changes above destruction of POA and shutdown of ORB were remove from ORBRunner class and: {code} // Ensure destroy is called on the root OA so that any pre/post destroy hooks get called // Normally we expect whoever called shutdown to have done this however destroy is // safe to call multiple times OA.getRootOA(this).destroy(); {code} code was added to ORBs shutdown method. The problem is that noone calls shutdown method neither as it was executed only from ORBRunner class. On the other when we execute shutdown method from ORBRunner class we are violating specification which also leads to a problems that we were solving in the first place. My suggestion would be to try perform destruction/shutdown in ORBRunner but only of the wrappers (without delegation to underlying ORB/POAs as we are sure they are already destroyed when ORBRunner runs). I'm preparing quick test of that solution now - will test it and paste it in few minutes if it passes the test (and tomorrow if it doesn't :) ). > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 04:19:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 16 Sep 2015 04:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109157#comment-13109157 ] Michael Musgrove commented on JBTM-2423: ---------------------------------------- [~tomekadamski] During the wildfly subsystem reload operation does org.jboss.as.txn.service.ArjunaRecoveryManagerService.stop get called. If it isn't called then that is where the bug is and if it is called then we need to debug why it doesn't clean up correctly. > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 04:29:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 16 Sep 2015 04:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109163#comment-13109163 ] Tomasz Adamski commented on JBTM-2423: -------------------------------------- https://issues.jboss.org/secure/ViewProfile.jspa?name=mmusgrov checking > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 04:29:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 16 Sep 2015 04:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109163#comment-13109163 ] Tomasz Adamski edited comment on JBTM-2423 at 9/16/15 4:29 AM: --------------------------------------------------------------- checking was (Author: tomekadamski): https://issues.jboss.org/secure/ViewProfile.jspa?name=mmusgrov checking > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 05:21:00 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 16 Sep 2015 05:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109163#comment-13109163 ] Tomasz Adamski edited comment on JBTM-2423 at 9/16/15 5:20 AM: --------------------------------------------------------------- The method runs but on the first glance I don't see orb shutdown performed from it. was (Author: tomekadamski): checking > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 11:23:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 16 Sep 2015 11:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does run orb an oa shutdown hooks In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2514: -------------------------------------- Summary: TransactionManagerService stop does run orb an oa shutdown hooks Key: JBTM-2514 URL: https://issues.jboss.org/browse/JBTM-2514 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Affects Versions: 5.2.2 Reporter: Michael Musgrove Assignee: Michael Musgrove The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 11:31:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 16 Sep 2015 11:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does run orb an oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/911 > TransactionManagerService stop does run orb an oa shutdown hooks > ---------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 11:37:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 16 Sep 2015 11:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb an oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Summary: TransactionManagerService stop does not run orb an oa shutdown hooks (was: TransactionManagerService stop does run orb an oa shutdown hooks) > TransactionManagerService stop does not run orb an oa shutdown hooks > -------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 11:43:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 16 Sep 2015 11:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2423) ORBRunner uses the orb after run() returns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2423. ---------------------------------- Resolution: Done I have raised JBTM-2514 to address the comment https://issues.jboss.org/browse/JBTM-2423?focusedCommentId=13109011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13109011 The reason for a new issue is that the underlying problem is different from this JIRA > ORBRunner uses the orb after run() returns > ------------------------------------------ > > Key: JBTM-2423 > URL: https://issues.jboss.org/browse/JBTM-2423 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > Fix For: 5.2.0 > > > ORBRunner.java starts an orb using orb().run() but then performs operations on the orb after the run() method returns. According to the CORBA spec this is invalid: > {quote} > Once an ORB has shutdown, only object reference management operations(duplicate, > release and is_nil) may be invoked on the ORB or any object reference obtained > from it. > {quote} > Note that when the orb.run() method returns the orb has shutdown because, for the run method, the spec states: > {quote} > This operation will block until the ORB has completed the shutdown process, > {quote} > This issue has arisen because of a change made to our fork of the jdk orb: in the jdk orb shutdown method we join with all the orb runners. This results in deadlock: > # com.arjuna.orbportability.ORB.shutdown is a synchronized method and it calls shutdown on the jdk orb; > # shutdown on the jdk orb notifies the ORBRunner thread which now tries to call back into a synchronized method of com.arjuna.orbportability.ORB but is blocked because the monitor is held > # at this point the jdk orb shutdown would normally then return allowing the > the ORBRunner thread to make progress but a recent change now means that the jdk orb shutdown method performs a join() on the various ORBRunner threads -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 16 11:45:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 16 Sep 2015 11:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Summary: TransactionManagerService stop does not run orb and oa shutdown hooks (was: TransactionManagerService stop does not run orb an oa shutdown hooks) > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 07:43:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 17 Sep 2015 07:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2515) Create script to update JIRA during the release In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2515: ------------------------------------- Summary: Create script to update JIRA during the release Key: JBTM-2515 URL: https://issues.jboss.org/browse/JBTM-2515 Project: JBoss Transaction Manager Issue Type: Sub-task Components: Release Process Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 07:49:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 17 Sep 2015 07:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2515) Create script to update JIRA during the release In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2515: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/912 > Create script to update JIRA during the release > ----------------------------------------------- > > Key: JBTM-2515 > URL: https://issues.jboss.org/browse/JBTM-2515 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Release Process > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 10:36:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 17 Sep 2015 10:36:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/911, https://github.com/jbosstm/narayana/pull/913 (was: https://github.com/jbosstm/narayana/pull/911) > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 17 10:38:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 17 Sep 2015 10:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110048#comment-13110048 ] Michael Musgrove commented on JBTM-2514: ---------------------------------------- I have added another PR to ensure that we do not shutdown the external orb (since other systems may still be using it). > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 18 06:28:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 18 Sep 2015 06:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2514: -------------------------------- Description: The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. In summary, the scope of the fix is: * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped * ensure that we do not shutdown an externally supplied orb was:The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 18 06:38:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 18 Sep 2015 06:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Affects Version/s: 5.0.4 > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.0.4, 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 18 06:39:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 18 Sep 2015 06:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Fix Version/s: 5.next > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.0.4, 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 18 06:45:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 18 Sep 2015 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Fix Version/s: 5.0.7 > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.0.4, 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next, 5.0.7 > > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 05:01:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 21 Sep 2015 05:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2516) Privileged actions in XTS In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2516: ------------------------------------- Summary: Privileged actions in XTS Key: JBTM-2516 URL: https://issues.jboss.org/browse/JBTM-2516 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next In some places we need to use PrivilegedAction in order to make XTS work with enabled security manager. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 05:05:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 21 Sep 2015 05:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2516) Privileged actions in XTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2516: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/915 > Privileged actions in XTS > ------------------------- > > Key: JBTM-2516 > URL: https://issues.jboss.org/browse/JBTM-2516 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > In some places we need to use PrivilegedAction in order to make XTS work with enabled security manager. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 08:24:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Sep 2015 08:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2517) Update the Narayana Release Process doc to include performance figures In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2517: -------------------------------------- Summary: Update the Narayana Release Process doc to include performance figures Key: JBTM-2517 URL: https://issues.jboss.org/browse/JBTM-2517 Project: JBoss Transaction Manager Issue Type: Task Components: Release Process Affects Versions: 5.2.2 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Include a description in the NRP document of how to blog about performance figures when releasing a new version of Narayana -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 08:26:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Sep 2015 08:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2518) Product comparison benchmark CI job fails with OutOfMemoryError In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2518: -------------------------------------- Summary: Product comparison benchmark CI job fails with OutOfMemoryError Key: JBTM-2518 URL: https://issues.jboss.org/browse/JBTM-2518 Project: JBoss Transaction Manager Issue Type: Bug Components: Performance Testing Affects Versions: 5.2.2 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/39 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 08:28:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Sep 2015 08:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/914 (was: https://github.com/jbosstm/narayana/pull/911, https://github.com/jbosstm/narayana/pull/913) > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.0.4, 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next, 5.0.7 > > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 09:27:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Sep 2015 09:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: (was: 5.next) Resolution: Done > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.0.4, 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.7 > > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 10:06:01 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 21 Sep 2015 10:06:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2516) Privileged actions in XTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2516: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Closing this pull request now in order to make TransactionalTestCase to work in WildFly. However, I'll create the follow up JIRA in order to do more thorough investigation of required permissions. > Privileged actions in XTS > ------------------------- > > Key: JBTM-2516 > URL: https://issues.jboss.org/browse/JBTM-2516 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > In some places we need to use PrivilegedAction in order to make XTS work with enabled security manager. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 10:08:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 21 Sep 2015 10:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2519) Investigate if XTS and RTS work with enabled security manager In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2519: ------------------------------------- Summary: Investigate if XTS and RTS work with enabled security manager Key: JBTM-2519 URL: https://issues.jboss.org/browse/JBTM-2519 Project: JBoss Transaction Manager Issue Type: Task Components: REST, XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 10:15:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 21 Sep 2015 10:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2515) Create script to update JIRA during the release In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2515: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Create script to update JIRA during the release > ----------------------------------------------- > > Key: JBTM-2515 > URL: https://issues.jboss.org/browse/JBTM-2515 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Release Process > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 10:39:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Sep 2015 10:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2517) Update the Narayana Release Process doc to include performance figures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2517: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > Update the Narayana Release Process doc to include performance figures > ---------------------------------------------------------------------- > > Key: JBTM-2517 > URL: https://issues.jboss.org/browse/JBTM-2517 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Include a description in the NRP document of how to blog about performance figures when releasing a new version of Narayana -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 21 12:15:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Sep 2015 12:15:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2520) standalone-cmr.xml wildfly config file out of date In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2520: -------------------------------------- Summary: standalone-cmr.xml wildfly config file out of date Key: JBTM-2520 URL: https://issues.jboss.org/browse/JBTM-2520 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.2.2 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The batch system config has changed so the wildfly cmr config file needs updating -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 04:55:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 04:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2520) standalone-cmr.xml wildfly config file out of date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2520. ------------------------------------ Resolution: Done fixed with commit f061a5f > standalone-cmr.xml wildfly config file out of date > -------------------------------------------------- > > Key: JBTM-2520 > URL: https://issues.jboss.org/browse/JBTM-2520 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The batch system config has changed so the wildfly cmr config file needs updating -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 04:56:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 04:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2518) Product comparison benchmark CI job fails with OutOfMemoryError In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2518: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > Product comparison benchmark CI job fails with OutOfMemoryError > --------------------------------------------------------------- > > Key: JBTM-2518 > URL: https://issues.jboss.org/browse/JBTM-2518 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/39 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 04:56:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 04:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2511) Benchmark failure testing REST-AT with undertow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2511: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > Benchmark failure testing REST-AT with undertow > ----------------------------------------------- > > Key: JBTM-2511 > URL: https://issues.jboss.org/browse/JBTM-2511 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing, REST > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > The REST-AT benchmark tests are failing: > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/37/ > and the failure is: > bq. Caused by: javax.ws.rs.ServiceUnavailableException: HTTP 503 Service Unavailable > whilst sending a request to a JAX-RS service. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:01:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2520) standalone-cmr.xml wildfly config file out of date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2520. ---------------------------------- > standalone-cmr.xml wildfly config file out of date > -------------------------------------------------- > > Key: JBTM-2520 > URL: https://issues.jboss.org/browse/JBTM-2520 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.3.Final > > > The batch system config has changed so the wildfly cmr config file needs updating -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:01:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2516) Privileged actions in XTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2516. ---------------------------------- > Privileged actions in XTS > ------------------------- > > Key: JBTM-2516 > URL: https://issues.jboss.org/browse/JBTM-2516 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.2.3.Final > > > In some places we need to use PrivilegedAction in order to make XTS work with enabled security manager. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:01:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2515) Create script to update JIRA during the release In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2515. ---------------------------------- > Create script to update JIRA during the release > ----------------------------------------------- > > Key: JBTM-2515 > URL: https://issues.jboss.org/browse/JBTM-2515 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Release Process > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.2.3.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:02:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2509) Failing narayana-benchmarks CI jobs are not marked as failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2509. ---------------------------------- > Failing narayana-benchmarks CI jobs are not marked as failed > ------------------------------------------------------------- > > Key: JBTM-2509 > URL: https://issues.jboss.org/browse/JBTM-2509 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.3.Final > > > For example the CI job http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/33/ failed running the REST-AT benchmark but the run was marked as passed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:02:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2508) Cannot enable logging in the qa test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2508. ---------------------------------- > Cannot enable logging in the qa test suite > ------------------------------------------ > > Key: JBTM-2508 > URL: https://issues.jboss.org/browse/JBTM-2508 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.3.Final > > > narayana uses jboss logging which requires an actual logging implementation (such as log4j or slf4j) on the classpath. Our distribution does not ship any default implementation so it is not possible to enable logging in our qa tests (which rely on the distribution). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:02:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2507) XTS qa test failures on IBM JDK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2507. ---------------------------------- > XTS qa test failures on IBM JDK > ------------------------------- > > Key: JBTM-2507 > URL: https://issues.jboss.org/browse/JBTM-2507 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.2.3.Final > > > {code} > Running com.arjuna.qa.junit.TestBACrashDuringCommit > Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2,179.93 sec <<< FAILURE! > MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(com.arjuna.qa.junit.TestBACrashDuringCommit) Time elapsed: 672.338 sec <<< ERROR! > java.lang.RuntimeException: jboss-as was not killed by Byteman, this indicates a test failure > at com.arjuna.qa.extension.BaseServerKillProcessor.kill(BaseServerKillProcessor.java:62) > at org.jboss.arquillian.container.impl.ContainerImpl.kill(ContainerImpl.java:235) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:193) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$10.perform(ContainerLifecycleController.java:187) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.killContainer(ContainerLifecycleController.java:186) > at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.kill(ClientContainerController.java:230) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:209) > at com.arjuna.qa.junit.TestBACrashDuringCommit.MultiParticipantCoordinatorCompletionParticipantCloseAndExitTest(TestBACrashDuringCommit.java:24) > {code} > {code} > Running com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare > Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 184.27 sec <<< FAILURE! > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.212 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container > at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:158) > at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:110) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:213) > at com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringPrepare.java:17) > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare) Time elapsed: 184.243 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:172) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > 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.RunAfters.evaluate(RunAfters.java:33) > at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:80) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createAfterContext(ContainerEventController.java:134) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.junit.extension.UpdateTestResultBeforeAfter.update(UpdateTestResultBeforeAfter.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:122) > at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259) > at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) > at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) > at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) > 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.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:02:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2506) BlackTie quickstarts fail to deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2506. ---------------------------------- > BlackTie quickstarts fail to deploy > ----------------------------------- > > Key: JBTM-2506 > URL: https://issues.jboss.org/browse/JBTM-2506 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.2.3.Final > > > {code} > [exec] [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.0.1.Final:deploy (default-cli) on project blacktie-quickstarts-integration1-ejb-ear: Could not execute goal deploy on /home/hudson/workspace/narayana-quickstarts/blacktie/integration1/ejb/ear/target/blacktie-quickstarts-integration1-ejb-ear-5.2.3.Final-SNAPSHOT.ear. Reason: I/O Error could not execute operation '{ > [exec] [ERROR] "operation" => "read-attribute", > [exec] [ERROR] "address" => [], > [exec] [ERROR] "name" => "launch-type" > [exec] [ERROR] }': java.net.ConnectException: JBAS012174: Could not connect to http-remoting://127.0.0.1:9990. The connection failed: For now upgrade responses must have a content length of zero. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:02:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:02:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2503) The deprecated api in the wildfly-blacktie has been removed in the wildfly-core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2503. ---------------------------------- > The deprecated api in the wildfly-blacktie has been removed in the wildfly-core > -------------------------------------------------------------------------------- > > Key: JBTM-2503 > URL: https://issues.jboss.org/browse/JBTM-2503 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.2.3.Final > > > It looks like the deprecated api has been removed in the wildfly-core upgrading to 2.0.0.Beta5. > http://albany.eng.hst.ams2.redhat.com/job/narayana-catelyn/989/console > http://albany.eng.hst.ams2.redhat.com/job/narayana/922/ > {code} > Caused by: java.lang.NoSuchMethodError: org.jboss.as.controller.registry.ManagementResourceRegistration.registerOperationHandler(Ljava/lang/String;Lorg/jboss/as/controller/OperationStepHandler;Lorg/jboss/as/controller/descriptions/DescriptionProvider;ZLorg/jboss/as/controller/registry/OperationEntry$EntryType;)V > at org.wildfly.extension.blacktie.BlacktieSubsystemExtension.initialize(BlacktieSubsystemExtension.java:80) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) [wildfly-controller-2.0.0.Beta5.jar:2.0.0.Beta5] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_45] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_45] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45] > at org.jboss.threads.JBossThread.run(JBossThread.java:320) [jboss-threads-2.2.1.Final.jar:2.2.1.Final] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:02:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:02:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2502) Raw XTS quickstart failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2502. ---------------------------------- > Raw XTS quickstart failure > -------------------------- > > Key: JBTM-2502 > URL: https://issues.jboss.org/browse/JBTM-2502 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.2.3.Final > > > Raw XTS quickstart test gets SOAPFaultException in every build. > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.jbossts.xts.demotest.XTSDemoTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 21.14 sec <<< FAILURE! > testBusinessActivity(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 3 sec <<< FAILURE! > java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testBusinessActivity(XTSDemoTest.java:101) > 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:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > 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:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > testAtomicTransaction(org.jboss.jbossts.xts.demotest.XTSDemoTest) Time elapsed: 0.297 sec <<< FAILURE! > java.lang.AssertionError: Transaction failed with: Transaction failed! Cause: javax.xml.ws.soap.SOAPFaultException: Fault occurred while processing. > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testReservation(XTSDemoTest.java:128) > at org.jboss.jbossts.xts.demotest.XTSDemoTest.testAtomicTransaction(XTSDemoTest.java:96) > 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:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > 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:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) > 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:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:02:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:02:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2501) Remove quickstart dependency on WildFly version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2501. ---------------------------------- > Remove quickstart dependency on WildFly version > ----------------------------------------------- > > Key: JBTM-2501 > URL: https://issues.jboss.org/browse/JBTM-2501 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.2.3.Final > > > Currently quickstarts use org.wildfly group to get managed and remote containers. This imposes dependency on the specific WildFly version. org.wildfly.arquillian had separate versioning from WildFly, thus it is easier to keep up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:03:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2499) Race condition between BlackTie subsystem and Artemis starting up In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2499. ---------------------------------- > Race condition between BlackTie subsystem and Artemis starting up > ----------------------------------------------------------------- > > Key: JBTM-2499 > URL: https://issues.jboss.org/browse/JBTM-2499 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.2.3.Final > > > Occasionally TcpServer tries to lookup ConnectionFactory before Artemis has started that component. > Solution is to delay the lookup until the subsystem is accessed which should work and at least will not bork the TcpServer thread and fail the entire subsystem until reboot. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:03:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2494) Product Comparison Benchmark missing dependency on Artemis In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2494. ---------------------------------- > Product Comparison Benchmark missing dependency on Artemis > ---------------------------------------------------------- > > Key: JBTM-2494 > URL: https://issues.jboss.org/browse/JBTM-2494 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.3.Final > > > The benchmark CI job (narayana-benchmarks) fails when doing a product comparison test: > {code} > java.lang.reflect.InvocationTargetException > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.arjuna.ats.arjuna.coordinator.TxControl > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:94) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:48) > at io.narayana.perf.product.ProductComparison.testNarayana(ProductComparison.java:69) > at io.narayana.perf.product.generated.ProductComparison_testNarayana.testNarayana_Throughput(ProductComparison_testNarayana.java:68) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:03:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2490) Possibility to run "qa" module with openjdk-orb In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2490. ---------------------------------- > Possibility to run "qa" module with openjdk-orb > ----------------------------------------------- > > Key: JBTM-2490 > URL: https://issues.jboss.org/browse/JBTM-2490 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.2.2 > Reporter: Hayk Hovsepyan > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.2.3.Final > > > In QA testing suites we have several jenkins jobs which are running Narayana's "qa" module tests with "jacorb" enabled. > The run of "qa" module is done via "scripts/hudson/narayana.sh" script with having appropriate environment variables. > "QA_TESTS=1" and "JAC_ORB=1" > We need to modify these jobs to run with "openjdk-orb" enabled. > So what we request: > Adjust "scripts/hudson/narayana.sh" script to be able to provide "OPENJDK_ORB=1" variable so it will run "qa" tests with "openjdk-orb". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:03:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:03:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2485) Close and release nexus deployed artifacts from build script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2485. ---------------------------------- > Close and release nexus deployed artifacts from build script > ------------------------------------------------------------ > > Key: JBTM-2485 > URL: https://issues.jboss.org/browse/JBTM-2485 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Optional > Fix For: 5.2.3.Final > > > Currently we need to visit the nexus site during NRP, it would be nice to be able to execute these steps from the command line as part of the release process. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:03:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:03:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2468) xts, jts and rts performance comparison job has failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2468. ---------------------------------- > xts, jts and rts performance comparison job has failures > -------------------------------------------------------- > > Key: JBTM-2468 > URL: https://issues.jboss.org/browse/JBTM-2468 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.2.3.Final > > > The weekly NCL jenkins job for performance comparison of jts/xts/rts has three issues: > - the throughput is coming out at 0 (I think it is because its very slow but it needs investigating); > - the jts component fails to configure wildfly into jts mode (I have temporarily disabled it in the job config); > - it runs against 9.0.0.Alpha2-SNAPSHOT (so it needs updating to run against the wildfly bi weekly builds) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:03:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2467) REST-AT undertow performance tests and quickstart fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2467. ---------------------------------- > REST-AT undertow performance tests and quickstart fail > ------------------------------------------------------ > > Key: JBTM-2467 > URL: https://issues.jboss.org/browse/JBTM-2467 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.3.Final > > > The REST-AT tests in the performance repo fail because the deployment to the undertow server used in the tests is failing -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:03:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2312) Wrong logging format of ARJUNA016005 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2312. ---------------------------------- > Wrong logging format of ARJUNA016005 > ------------------------------------ > > Key: JBTM-2312 > URL: https://issues.jboss.org/browse/JBTM-2312 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.24 > Reporter: Ond?ej Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.2.3.Final > > > Logging format of warning warn_recovery_failedtorecover is strange or maybe better to say wrong. It looks: > {code} > WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016005: JTS XARecoveryModule.xaRecovery - failed to recover XAResource. status is $2 > {code} > This message came from XAResourceRecord.xaRecoverySecondPass and it's message warn_recovery_failedtorecover. The code with dolar sign seems to me a bit confusing. > I think it would be better first not have the dolar sign there and second rather to print string representation of the error code. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2296) Provide better way of distributing IOR to users In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2296. ---------------------------------- > Provide better way of distributing IOR to users > ----------------------------------------------- > > Key: JBTM-2296 > URL: https://issues.jboss.org/browse/JBTM-2296 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Cloud, JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.2.3.Final > > > Original JIRA shows I used github. Maybe that's fine. Maybe not. Consider other options (too, or instead). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2519) Investigate if XTS and RTS work with enabled security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2519: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Investigate if XTS and RTS work with enabled security manager > ------------------------------------------------------------- > > Key: JBTM-2519 > URL: https://issues.jboss.org/browse/JBTM-2519 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2513) Put build to undocumented, if it has anything other that JIRA id in description In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2513: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Put build to undocumented, if it has anything other that JIRA id in description > ------------------------------------------------------------------------------- > > Key: JBTM-2513 > URL: https://issues.jboss.org/browse/JBTM-2513 > Project: JBoss Transaction Manager > Issue Type: Task > Components: CI Report Generator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2512) Include BlackTie javadoc on Narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2512: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Include BlackTie javadoc on Narayana.io > --------------------------------------- > > Key: JBTM-2512 > URL: https://issues.jboss.org/browse/JBTM-2512 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2510) Provide some example jbossts-properties.xml on the narayana.io site In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2510: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Provide some example jbossts-properties.xml on the narayana.io site > ------------------------------------------------------------------- > > Key: JBTM-2510 > URL: https://issues.jboss.org/browse/JBTM-2510 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > This will mean we don't need to download the zip to use them (for say maven users). > We should provide: > local JTA > jacorb JTS > JDKORB JTS > IBMORB JTS -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2505: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2504) Investigate why throughput of JTS performance comparison test is 0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2504: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Investigate why throughput of JTS performance comparison test is 0 > ------------------------------------------------------------------ > > Key: JBTM-2504 > URL: https://issues.jboss.org/browse/JBTM-2504 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > We need to investigate why throughput of JTS performance comparison test is coming out at 0 ([~mmusgrov] thinks it is because it`s very slow); -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2497) Update or remove references of HornetQ to Artemis In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2497: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Update or remove references of HornetQ to Artemis > ------------------------------------------------- > > Key: JBTM-2497 > URL: https://issues.jboss.org/browse/JBTM-2497 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie, Demonstrator, Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > There were reports of HornetQ still in at least the fooapp QS. We should try to remove references to the specific implementation unless necessary and in those cases use the correct name which is now Artemis. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2495) Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2495: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2495 > URL: https://issues.jboss.org/browse/JBTM-2495 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Documentation > Affects Versions: 5.0.0.M2 > Environment: RHEL 6.3 > Reporter: Joice Joy > Assignee: Amos Feng > Fix For: 5.next > > > I am installing Blacktie 5.2.2 Final with Wildfly 9.0.1 but the Wildfly server fails to start the Blacktie service > But the server does not start the blacktie service: > This is from quickstart quickstart/blacktie > > > > ========================================================================= > > > JBoss Bootstrap Environment > > > JBOSS_HOME: /fxtest/trep/wildfly/wildfly-9.0.1.Final > > > JAVA: /fxtest/trep/java/jdk1.8.0_51/bin/java > > > JAVA_OPTS: -server -XX:+UseCompressedOops -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE > > > ========================================================================= > > > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 > 07:35:52,490 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final > 07:35:52,892 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 07:35:53,007 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0049: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) starting > 07:35:55,053 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'job-repository-type' in the resource at address '/subsystem=batch' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,055 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,121 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment blacktie-admin-services-ear-5.2.2.Final.ear > 07:35:55,361 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 24) WFLYDR0001: Content added at location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:55,390 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 07:35:55,422 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final > 07:35:55,438 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.1.Final > 07:35:55,482 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.9.Final > 07:35:55,548 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > 07:35:55,554 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > 07:35:55,557 INFO [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 42) WFLYIIOP0001: Activating IIOP Subsystem > 07:35:55,602 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.4.Final) > 07:35:55,615 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > 07:35:55,652 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 07:35:55,661 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > 07:35:55,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0018: Started Driver service with driver-name = h2 > 07:35:55,827 INFO [org.jboss.as.security] (ServerService Thread Pool -- 59) WFLYSEC0002: Activating Security Subsystem > 07:35:55,829 INFO [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=4.9.2.Final > 07:35:55,849 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 07:35:55,849 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > 07:35:55,998 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,034 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,095 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 07:35:56,119 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 07:35:56,352 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path /fxtest/trep/wildfly/wildfly-9.0.1.Final/welcome-content > 07:35:56,417 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server. > 07:35:56,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > 07:35:56,589 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 07:35:56,945 INFO [org.wildfly.iiop.openjdk] (MSC service thread 1-3) WFLYIIOP0009: CORBA ORB Service started > 07:35:56,969 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 07:35:57,030 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/deployments > 07:35:57,059 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:57,187 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221000: live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingjournal,bindingsDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingbindings,largeMessagesDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messaginglargemessages,pagingDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingpaging) > 07:35:57,193 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221006: Waiting to obtain live lock > 07:35:57,287 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221012: Using AIO Journal > 07:35:57,387 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support CORE > 07:35:57,414 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Final > 07:35:57,439 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support AMQP > 07:35:57,443 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support STOMP > 07:35:57,502 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221034: Waiting to obtain live lock > 07:35:57,504 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221035: Live Server Obtained live lock > 07:35:58,108 INFO [org.jboss.messaging] (MSC service thread 1-3) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor acceptor > 07:35:58,112 INFO [org.jboss.messaging] (MSC service thread 1-1) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor-throughput acceptor > 07:35:58,206 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221007: Server is now live > 07:35:58,207 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221001: HornetQ Server version 2.4.7.Final (2.4.7.Final, 124) [9d12c6a3-4666-11e5-8632-95a54ac84561] > 07:35:58,210 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221003: trying to deploy queue jms.queue.ExpiryQueue > 07:35:58,514 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 66) WFLYMSG0002: Bound messaging object to jndi name java:/ConnectionFactory > 07:35:58,519 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 67) WFLYMSG0002: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory > 07:35:58,519 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 65) HQ221003: trying to deploy queue jms.queue.DLQ > 07:35:58,623 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0007: Registered connection factory java:/JmsXA > 07:35:58,721 INFO [org.hornetq.ra] (MSC service thread 1-4) HornetQ resource adaptor started > 07:35:58,721 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) IJ020002: Deployed: file://RaActivatorhornetq-ra > 07:35:58,733 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0002: Bound JCA ConnectionFactory [java:/JmsXA] > 07:35:58,733 INFO [org.jboss.as.messaging] (MSC service thread 1-4) WFLYMSG0002: Bound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-impl.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jsr173_1.0_api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,763 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry activation.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "blacktie-admin-services-5.2.2.Final.jar") > 07:35:58,885 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:98) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95) > ... 6 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment' > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89) > ... 6 more > > > 07:35:58,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "blacktie-admin-services-ear-5.2.2.Final.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"blacktie-admin-services-5.2.2.Final.jar\" of deployment \"blacktie-admin-services-ear-5.2.2.Final.ear\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment'"}} > 07:35:58,980 INFO [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name : "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:58,982 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > > > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 07:35:59,202 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 7156ms - Started 247 of 423 services (2 services failed or missing dependencies, 222 services are lazy, passive or on-demand) > 07:35:59,243 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: blacktie-admin-services-5.2.2.Final.jar) in 9ms > 07:35:59,332 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment blacktie-admin-services-ear-5.2.2.Final.ear (runtime-name: blacktie-admin-services-ear-5.2.2.Final.ear) in 98ms > 07:35:59,413 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0002: Content removed from location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:59,414 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:59,414 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2492) Build and deploy Blacktie as part of BRP.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2492: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Build and deploy Blacktie as part of BRP.xml > -------------------------------------------- > > Key: JBTM-2492 > URL: https://issues.jboss.org/browse/JBTM-2492 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > We only update the Blacktie java artifacts so these should be able to be done from any machine: > {code} > call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" > build.bat -f blacktie\wildfly-blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml deploy -DskipTests > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2491) JTS and JacORB NS Docker images quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2491: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > JTS and JacORB NS Docker images quickstart > ------------------------------------------ > > Key: JBTM-2491 > URL: https://issues.jboss.org/browse/JBTM-2491 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a quickstart for JTS and JacORB Name Server Docker images. > Additionally, add Kubernetes pod configuration for that. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2481) Automate NRP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2481: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Automate NRP > ------------ > > Key: JBTM-2481 > URL: https://issues.jboss.org/browse/JBTM-2481 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > There are a number of steps on NRP that could be automated using Jira API. > Lets try to do that: > https://community.jboss.org/wiki/NarayanaReleaseProcess -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:04:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2480: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2476) When a transaction times out, print the stack traces of the threads involved In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2476: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > When a transaction times out, print the stack traces of the threads involved > ---------------------------------------------------------------------------- > > Key: JBTM-2476 > URL: https://issues.jboss.org/browse/JBTM-2476 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Would be useful to help understand what the code was doing when the transaction times out. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2458: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2433) TransactionRolledBackException in MultiCloseTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2433: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > TransactionRolledBackException in MultiCloseTest > ------------------------------------------------ > > Key: JBTM-2433 > URL: https://issues.jboss.org/browse/JBTM-2433 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > Attachments: com.arjuna.wstx.tests.arq.ba.MultiCloseTest-output.txt > > > It looks like this failure has been caused by the race condition in WS-BA. In our tests it should be handled by the Byteman rule, but seems that for an unknown reason it has still failed in this occasion. > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.ba.MultiCloseTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.117 sec <<< FAILURE! > testMultiClose(com.arjuna.wstx.tests.arq.ba.MultiCloseTest) Time elapsed: 2.5 sec <<< ERROR! > com.arjuna.wst.TransactionRolledBackException: null > at com.arjuna.wst11.stub.BusinessActivityTerminatorStub.close(BusinessActivityTerminatorStub.java:95) > at com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple.close(UserBusinessActivityImple.java:157) > at com.arjuna.wstx.tests.arq.ba.MultiCloseTest.testMultiClose(MultiCloseTest.java:71) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2409: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > Attachments: 32287.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Use Project Atomic for docker image(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2298: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Use Project Atomic for docker image(s) > -------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS, REST, XTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2234) out of memory when logging more messages than heap size (surefire issue) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2234: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > out of memory when logging more messages than heap size (surefire issue) > ------------------------------------------------------------------------ > > Key: JBTM-2234 > URL: https://issues.jboss.org/browse/JBTM-2234 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.0.2 > Environment: JTS testing > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Optional > Fix For: 5.next > > > Running com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 on JacORB with about 500000 transactions results in an OOM error because surefire keeps in logs in memory until the test has finished. > In this particular test jacorb logs messages at INFO level for each transaction resulting in excessive memory requirements. We can't make the heap too large because the default JVM is 32 bit. However, we could fix it by reducing the jacorb log level to WARN. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2206: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2203: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2180) Determine whether or not we should use a specific collections framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2180: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Determine whether or not we should use a specific collections framework > ----------------------------------------------------------------------- > > Key: JBTM-2180 > URL: https://issues.jboss.org/browse/JBTM-2180 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA, JTS, Performance Testing, REST, Transaction Core > Affects Versions: 5.0.1 > Reporter: Mark Little > Assignee: Tom Jenkinson > Priority: Optional > Fix For: 5.next > > > We use many of the inbuilt collections implementations (such as Hashtable) which are well known to be suboptimal in certain cases. Should we use a separate collections framework, e.g., https://github.com/goldmansachs/gs-collections > There are pros and cons of doing this. But first we need to determine whether it really makes sense from a performance perspective. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2120) Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2120: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2120 > URL: https://issues.jboss.org/browse/JBTM-2120 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Pull https://github.com/jbosstm/narayana/pull/598 added deferred throwables in case the XAR::end fails during commit. It doesn't handle the case of the HEURISTIC_ROLLBACK of a first resource where Narayana rolls back the remaining participants and then clears the failed/heuristic lists (and marks the txn as rolled back). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2115: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2110: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1854: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1804: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:04 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1340) BeanPopulator overhead needs looking into In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1340: ----------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > BeanPopulator overhead needs looking into > ----------------------------------------- > > Key: JBTM-1340 > URL: https://issues.jboss.org/browse/JBTM-1340 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Common > Affects Versions: 4.17.2 > Environment: Mac OS 10.7 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.next > > > During profiling, BeanPopulator can represent a 7% overhead. It may not seem like a lot, but for something as relatively simple as what BeanPopulator should be doing, it seems to be quite a bit. > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.coordinator.TxStats.enabled > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance > 2.5% - 1,587 ms - 10,000 inv. java.lang.StringBuilder. > 2.3% - 1,507 ms - 10,000 inv. java.lang.StringBuilder.toString > 0.0% - 320 ?s - 10,000 inv. java.util.concurrent.ConcurrentMap.containsKey > 0.0% - 61 ?s - 10,000 inv. java.lang.Class.getName > 0.0% - 25 ?s - 10,000 inv. java.util.concurrent.ConcurrentMap.get -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:05:04 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:05:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-855) Create an example showing integration with Spring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-855: ---------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Create an example showing integration with Spring > ------------------------------------------------- > > Key: JBTM-855 > URL: https://issues.jboss.org/browse/JBTM-855 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > Original Estimate: 1 week > Remaining Estimate: 1 week > > The main thing is to show the config but we need to provide an example that shows how to ensure the XAResources are available for recovery -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:06:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-741) Remove redundant XTS classes and code paths identified from coverage data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-741: ---------------------------------- Fix Version/s: 5.next (was: 5.2.3.Final) > Remove redundant XTS classes and code paths identified from coverage data > ------------------------------------------------------------------------- > > Key: JBTM-741 > URL: https://issues.jboss.org/browse/JBTM-741 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 4.11.0 > Reporter: Andrew Dinn > Assignee: Gytis Trikleris > Fix For: 5.next > > > Coverage analysis of the XTS code base has idenitifed a lot of unexercised classes and code paths. These need pruning in order to simplify maintenance and testing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:22:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 22 Sep 2015 05:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2504) Investigate why throughput of JTS performance comparison test is 0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2504: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/performance/pull/23 > Investigate why throughput of JTS performance comparison test is 0 > ------------------------------------------------------------------ > > Key: JBTM-2504 > URL: https://issues.jboss.org/browse/JBTM-2504 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > We need to investigate why throughput of JTS performance comparison test is coming out at 0 ([~mmusgrov] thinks it is because it`s very slow); -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:25:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2514: ----------------------------------- Fix Version/s: 5.2.3.Final (was: 5.0.7) > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.0.4, 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.3.Final > > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 05:25:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 05:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2514) TransactionManagerService stop does not run orb and oa shutdown hooks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2514. ---------------------------------- > TransactionManagerService stop does not run orb and oa shutdown hooks > --------------------------------------------------------------------- > > Key: JBTM-2514 > URL: https://issues.jboss.org/browse/JBTM-2514 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.0.4, 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.3.Final > > > The transaction manager service that we use for integration with app servers in JTS mode (com.arjuna.ats.jbossatx.jts.TransactionManagerService()) does not run any of our orb shutdown hooks in its stop method. The reason for this is that we use an orb supplied by the app server which we do not wrap so none of the shutdown hooks in our wrappers get called. In particular the JavaIdlRCShutdown hook isn't called so it is not possible to restart the RecoveryService (see JavaIdlRCServiceInit) with the consequence that the wildfly reload management operation fails. > In summary, the scope of the fix is: > * ensure that our (orb portablility layer) shutdown hooks are called when the TM service is stopped > * ensure that we do not shutdown an externally supplied orb -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 07:38:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 22 Sep 2015 07:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2504) Investigate why throughput of JTS performance comparison test is 0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2504: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Investigate why throughput of JTS performance comparison test is 0 > ------------------------------------------------------------------ > > Key: JBTM-2504 > URL: https://issues.jboss.org/browse/JBTM-2504 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > We need to investigate why throughput of JTS performance comparison test is coming out at 0 ([~mmusgrov] thinks it is because it`s very slow); -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 07:42:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 22 Sep 2015 07:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111209#comment-13111209 ] Gytis Trikleris commented on JBTM-2505: --------------------------------------- http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-AS800/819/ http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-AS800/820/ > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 08:07:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 22 Sep 2015 08:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2513) Put build to undocumented, if it has anything other that JIRA id in description In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2513: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/ci-report-generator/pull/2 > Put build to undocumented, if it has anything other that JIRA id in description > ------------------------------------------------------------------------------- > > Key: JBTM-2513 > URL: https://issues.jboss.org/browse/JBTM-2513 > Project: JBoss Transaction Manager > Issue Type: Task > Components: CI Report Generator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 08:08:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 22 Sep 2015 08:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2513) Put build to undocumented, if it has anything other that JIRA id in description In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2513: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Put build to undocumented, if it has anything other that JIRA id in description > ------------------------------------------------------------------------------- > > Key: JBTM-2513 > URL: https://issues.jboss.org/browse/JBTM-2513 > Project: JBoss Transaction Manager > Issue Type: Task > Components: CI Report Generator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 12:33:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 12:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2521) Blacktie wildfly config files need updating In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2521: -------------------------------------- Summary: Blacktie wildfly config files need updating Key: JBTM-2521 URL: https://issues.jboss.org/browse/JBTM-2521 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Affects Versions: 5.2.3.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Arquillian deployements fail because the wildfly config files are out of date (batch -> batch-jberet). An example is: http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el6/935/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 12:38:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 12:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2521) Blacktie wildfly config files need updating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2521: -------------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > Blacktie wildfly config files need updating > ------------------------------------------- > > Key: JBTM-2521 > URL: https://issues.jboss.org/browse/JBTM-2521 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.2.3.Final > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > > Arquillian deployements fail because the wildfly config files are out of date (batch -> batch-jberet). An example is: > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el6/935/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 12:38:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 22 Sep 2015 12:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2521) Blacktie wildfly config files need updating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2521: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/916 > Blacktie wildfly config files need updating > ------------------------------------------- > > Key: JBTM-2521 > URL: https://issues.jboss.org/browse/JBTM-2521 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.2.3.Final > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > > Arquillian deployements fail because the wildfly config files are out of date (batch -> batch-jberet). An example is: > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el6/935/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 16:03:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 16:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2521) Blacktie wildfly config files need updating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2521: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Blacktie wildfly config files need updating > ------------------------------------------- > > Key: JBTM-2521 > URL: https://issues.jboss.org/browse/JBTM-2521 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.2.3.Final > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > > Arquillian deployements fail because the wildfly config files are out of date (batch -> batch-jberet). An example is: > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el6/935/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2521) Blacktie wildfly config files need updating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2521. ------------------------------- > Blacktie wildfly config files need updating > ------------------------------------------- > > Key: JBTM-2521 > URL: https://issues.jboss.org/browse/JBTM-2521 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.2.3.Final > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.2.4.Final > > > Arquillian deployements fail because the wildfly config files are out of date (batch -> batch-jberet). An example is: > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el6/935/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2513) Put build to undocumented, if it has anything other that JIRA id in description In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2513. ------------------------------- > Put build to undocumented, if it has anything other that JIRA id in description > ------------------------------------------------------------------------------- > > Key: JBTM-2513 > URL: https://issues.jboss.org/browse/JBTM-2513 > Project: JBoss Transaction Manager > Issue Type: Task > Components: CI Report Generator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.2.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2504) Investigate why throughput of JTS performance comparison test is 0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2504. ------------------------------- > Investigate why throughput of JTS performance comparison test is 0 > ------------------------------------------------------------------ > > Key: JBTM-2504 > URL: https://issues.jboss.org/browse/JBTM-2504 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.2.4.Final > > > We need to investigate why throughput of JTS performance comparison test is coming out at 0 ([~mmusgrov] thinks it is because it`s very slow); -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2519) Investigate if XTS and RTS work with enabled security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2519: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Investigate if XTS and RTS work with enabled security manager > ------------------------------------------------------------- > > Key: JBTM-2519 > URL: https://issues.jboss.org/browse/JBTM-2519 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2512) Include BlackTie javadoc on Narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2512: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Include BlackTie javadoc on Narayana.io > --------------------------------------- > > Key: JBTM-2512 > URL: https://issues.jboss.org/browse/JBTM-2512 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2510) Provide some example jbossts-properties.xml on the narayana.io site In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2510: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Provide some example jbossts-properties.xml on the narayana.io site > ------------------------------------------------------------------- > > Key: JBTM-2510 > URL: https://issues.jboss.org/browse/JBTM-2510 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > This will mean we don't need to download the zip to use them (for say maven users). > We should provide: > local JTA > jacorb JTS > JDKORB JTS > IBMORB JTS -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2505: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2495) Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2495: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2495 > URL: https://issues.jboss.org/browse/JBTM-2495 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Documentation > Affects Versions: 5.0.0.M2 > Environment: RHEL 6.3 > Reporter: Joice Joy > Assignee: Amos Feng > Fix For: 5.next > > > I am installing Blacktie 5.2.2 Final with Wildfly 9.0.1 but the Wildfly server fails to start the Blacktie service > But the server does not start the blacktie service: > This is from quickstart quickstart/blacktie > > > > ========================================================================= > > > JBoss Bootstrap Environment > > > JBOSS_HOME: /fxtest/trep/wildfly/wildfly-9.0.1.Final > > > JAVA: /fxtest/trep/java/jdk1.8.0_51/bin/java > > > JAVA_OPTS: -server -XX:+UseCompressedOops -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE > > > ========================================================================= > > > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 > 07:35:52,490 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final > 07:35:52,892 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 07:35:53,007 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0049: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) starting > 07:35:55,053 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'job-repository-type' in the resource at address '/subsystem=batch' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,055 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,121 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment blacktie-admin-services-ear-5.2.2.Final.ear > 07:35:55,361 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 24) WFLYDR0001: Content added at location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:55,390 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 07:35:55,422 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final > 07:35:55,438 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.1.Final > 07:35:55,482 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.9.Final > 07:35:55,548 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > 07:35:55,554 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > 07:35:55,557 INFO [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 42) WFLYIIOP0001: Activating IIOP Subsystem > 07:35:55,602 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.4.Final) > 07:35:55,615 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > 07:35:55,652 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 07:35:55,661 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > 07:35:55,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0018: Started Driver service with driver-name = h2 > 07:35:55,827 INFO [org.jboss.as.security] (ServerService Thread Pool -- 59) WFLYSEC0002: Activating Security Subsystem > 07:35:55,829 INFO [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=4.9.2.Final > 07:35:55,849 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 07:35:55,849 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > 07:35:55,998 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,034 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,095 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 07:35:56,119 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 07:35:56,352 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path /fxtest/trep/wildfly/wildfly-9.0.1.Final/welcome-content > 07:35:56,417 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server. > 07:35:56,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > 07:35:56,589 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 07:35:56,945 INFO [org.wildfly.iiop.openjdk] (MSC service thread 1-3) WFLYIIOP0009: CORBA ORB Service started > 07:35:56,969 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 07:35:57,030 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/deployments > 07:35:57,059 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:57,187 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221000: live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingjournal,bindingsDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingbindings,largeMessagesDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messaginglargemessages,pagingDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingpaging) > 07:35:57,193 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221006: Waiting to obtain live lock > 07:35:57,287 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221012: Using AIO Journal > 07:35:57,387 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support CORE > 07:35:57,414 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Final > 07:35:57,439 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support AMQP > 07:35:57,443 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support STOMP > 07:35:57,502 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221034: Waiting to obtain live lock > 07:35:57,504 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221035: Live Server Obtained live lock > 07:35:58,108 INFO [org.jboss.messaging] (MSC service thread 1-3) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor acceptor > 07:35:58,112 INFO [org.jboss.messaging] (MSC service thread 1-1) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor-throughput acceptor > 07:35:58,206 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221007: Server is now live > 07:35:58,207 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221001: HornetQ Server version 2.4.7.Final (2.4.7.Final, 124) [9d12c6a3-4666-11e5-8632-95a54ac84561] > 07:35:58,210 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221003: trying to deploy queue jms.queue.ExpiryQueue > 07:35:58,514 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 66) WFLYMSG0002: Bound messaging object to jndi name java:/ConnectionFactory > 07:35:58,519 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 67) WFLYMSG0002: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory > 07:35:58,519 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 65) HQ221003: trying to deploy queue jms.queue.DLQ > 07:35:58,623 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0007: Registered connection factory java:/JmsXA > 07:35:58,721 INFO [org.hornetq.ra] (MSC service thread 1-4) HornetQ resource adaptor started > 07:35:58,721 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) IJ020002: Deployed: file://RaActivatorhornetq-ra > 07:35:58,733 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0002: Bound JCA ConnectionFactory [java:/JmsXA] > 07:35:58,733 INFO [org.jboss.as.messaging] (MSC service thread 1-4) WFLYMSG0002: Bound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-impl.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jsr173_1.0_api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,763 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry activation.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "blacktie-admin-services-5.2.2.Final.jar") > 07:35:58,885 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:98) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95) > ... 6 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment' > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89) > ... 6 more > > > 07:35:58,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "blacktie-admin-services-ear-5.2.2.Final.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"blacktie-admin-services-5.2.2.Final.jar\" of deployment \"blacktie-admin-services-ear-5.2.2.Final.ear\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment'"}} > 07:35:58,980 INFO [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name : "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:58,982 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > > > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 07:35:59,202 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 7156ms - Started 247 of 423 services (2 services failed or missing dependencies, 222 services are lazy, passive or on-demand) > 07:35:59,243 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: blacktie-admin-services-5.2.2.Final.jar) in 9ms > 07:35:59,332 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment blacktie-admin-services-ear-5.2.2.Final.ear (runtime-name: blacktie-admin-services-ear-5.2.2.Final.ear) in 98ms > 07:35:59,413 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0002: Content removed from location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:59,414 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:59,414 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2497) Update or remove references of HornetQ to Artemis In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2497: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Update or remove references of HornetQ to Artemis > ------------------------------------------------- > > Key: JBTM-2497 > URL: https://issues.jboss.org/browse/JBTM-2497 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie, Demonstrator, Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > There were reports of HornetQ still in at least the fooapp QS. We should try to remove references to the specific implementation unless necessary and in those cases use the correct name which is now Artemis. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2492) Build and deploy Blacktie as part of BRP.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2492: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Build and deploy Blacktie as part of BRP.xml > -------------------------------------------- > > Key: JBTM-2492 > URL: https://issues.jboss.org/browse/JBTM-2492 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > We only update the Blacktie java artifacts so these should be able to be done from any machine: > {code} > call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" > build.bat -f blacktie\wildfly-blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml deploy -DskipTests > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:40:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2491) JTS and JacORB NS Docker images quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2491: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > JTS and JacORB NS Docker images quickstart > ------------------------------------------ > > Key: JBTM-2491 > URL: https://issues.jboss.org/browse/JBTM-2491 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a quickstart for JTS and JacORB Name Server Docker images. > Additionally, add Kubernetes pod configuration for that. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2481) Automate NRP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2481: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Automate NRP > ------------ > > Key: JBTM-2481 > URL: https://issues.jboss.org/browse/JBTM-2481 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > There are a number of steps on NRP that could be automated using Jira API. > Lets try to do that: > https://community.jboss.org/wiki/NarayanaReleaseProcess -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2480: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2476) When a transaction times out, print the stack traces of the threads involved In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2476: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > When a transaction times out, print the stack traces of the threads involved > ---------------------------------------------------------------------------- > > Key: JBTM-2476 > URL: https://issues.jboss.org/browse/JBTM-2476 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Would be useful to help understand what the code was doing when the transaction times out. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2433) TransactionRolledBackException in MultiCloseTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2433: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > TransactionRolledBackException in MultiCloseTest > ------------------------------------------------ > > Key: JBTM-2433 > URL: https://issues.jboss.org/browse/JBTM-2433 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > Attachments: com.arjuna.wstx.tests.arq.ba.MultiCloseTest-output.txt > > > It looks like this failure has been caused by the race condition in WS-BA. In our tests it should be handled by the Byteman rule, but seems that for an unknown reason it has still failed in this occasion. > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.ba.MultiCloseTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.117 sec <<< FAILURE! > testMultiClose(com.arjuna.wstx.tests.arq.ba.MultiCloseTest) Time elapsed: 2.5 sec <<< ERROR! > com.arjuna.wst.TransactionRolledBackException: null > at com.arjuna.wst11.stub.BusinessActivityTerminatorStub.close(BusinessActivityTerminatorStub.java:95) > at com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple.close(UserBusinessActivityImple.java:157) > at com.arjuna.wstx.tests.arq.ba.MultiCloseTest.testMultiClose(MultiCloseTest.java:71) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2409: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > Attachments: 32287.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2458: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Use Project Atomic for docker image(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2298: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Use Project Atomic for docker image(s) > -------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS, REST, XTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2234) out of memory when logging more messages than heap size (surefire issue) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2234: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > out of memory when logging more messages than heap size (surefire issue) > ------------------------------------------------------------------------ > > Key: JBTM-2234 > URL: https://issues.jboss.org/browse/JBTM-2234 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.0.2 > Environment: JTS testing > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Optional > Fix For: 5.next > > > Running com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 on JacORB with about 500000 transactions results in an OOM error because surefire keeps in logs in memory until the test has finished. > In this particular test jacorb logs messages at INFO level for each transaction resulting in excessive memory requirements. We can't make the heap too large because the default JVM is 32 bit. However, we could fix it by reducing the jacorb log level to WARN. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2206: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2203: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2180) Determine whether or not we should use a specific collections framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2180: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Determine whether or not we should use a specific collections framework > ----------------------------------------------------------------------- > > Key: JBTM-2180 > URL: https://issues.jboss.org/browse/JBTM-2180 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA, JTS, Performance Testing, REST, Transaction Core > Affects Versions: 5.0.1 > Reporter: Mark Little > Assignee: Tom Jenkinson > Priority: Optional > Fix For: 5.next > > > We use many of the inbuilt collections implementations (such as Hashtable) which are well known to be suboptimal in certain cases. Should we use a separate collections framework, e.g., https://github.com/goldmansachs/gs-collections > There are pros and cons of doing this. But first we need to determine whether it really makes sense from a performance perspective. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2120) Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2120: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2120 > URL: https://issues.jboss.org/browse/JBTM-2120 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Pull https://github.com/jbosstm/narayana/pull/598 added deferred throwables in case the XAR::end fails during commit. It doesn't handle the case of the HEURISTIC_ROLLBACK of a first resource where Narayana rolls back the remaining participants and then clears the failed/heuristic lists (and marks the txn as rolled back). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2115: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2110: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1854: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1340) BeanPopulator overhead needs looking into In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1340: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > BeanPopulator overhead needs looking into > ----------------------------------------- > > Key: JBTM-1340 > URL: https://issues.jboss.org/browse/JBTM-1340 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Common > Affects Versions: 4.17.2 > Environment: Mac OS 10.7 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.next > > > During profiling, BeanPopulator can represent a 7% overhead. It may not seem like a lot, but for something as relatively simple as what BeanPopulator should be doing, it seems to be quite a bit. > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.coordinator.TxStats.enabled > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance > 2.5% - 1,587 ms - 10,000 inv. java.lang.StringBuilder. > 2.3% - 1,507 ms - 10,000 inv. java.lang.StringBuilder.toString > 0.0% - 320 ?s - 10,000 inv. java.util.concurrent.ConcurrentMap.containsKey > 0.0% - 61 ?s - 10,000 inv. java.lang.Class.getName > 0.0% - 25 ?s - 10,000 inv. java.util.concurrent.ConcurrentMap.get -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1804: -------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-855) Create an example showing integration with Spring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-855: ------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Create an example showing integration with Spring > ------------------------------------------------- > > Key: JBTM-855 > URL: https://issues.jboss.org/browse/JBTM-855 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > Original Estimate: 1 week > Remaining Estimate: 1 week > > The main thing is to show the config but we need to provide an example that shows how to ensure the XAResources are available for recovery -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 22 17:41:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 22 Sep 2015 17:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-741) Remove redundant XTS classes and code paths identified from coverage data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-741: ------------------------------- Fix Version/s: 5.next (was: 5.2.4.Final) > Remove redundant XTS classes and code paths identified from coverage data > ------------------------------------------------------------------------- > > Key: JBTM-741 > URL: https://issues.jboss.org/browse/JBTM-741 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 4.11.0 > Reporter: Andrew Dinn > Assignee: Gytis Trikleris > Fix For: 5.next > > > Coverage analysis of the XTS code base has idenitifed a lot of unexercised classes and code paths. These need pruning in order to simplify maintenance and testing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 04:50:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 23 Sep 2015 04:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2522) Update performance comparison tests to use JMH In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2522: ------------------------------------- Summary: Update performance comparison tests to use JMH Key: JBTM-2522 URL: https://issues.jboss.org/browse/JBTM-2522 Project: JBoss Transaction Manager Issue Type: Task Components: Performance Testing Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 04:51:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 23 Sep 2015 04:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2522) Update performance comparison tests to use JMH In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2522 started by Gytis Trikleris. --------------------------------------------- > Update performance comparison tests to use JMH > ---------------------------------------------- > > Key: JBTM-2522 > URL: https://issues.jboss.org/browse/JBTM-2522 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 06:49:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 23 Sep 2015 06:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2505: -------------------------------- Attachment: consoleText.txt > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > Attachments: consoleText.txt > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 06:51:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 23 Sep 2015 06:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111613#comment-13111613 ] Tom Jenkinson commented on JBTM-2505: ------------------------------------- I have attached the log from the console as there isn't much else to go on. That being said we have had subsequent builds pass on brandon so I hope it was resolved but... > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > Attachments: consoleText.txt > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 06:52:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 23 Sep 2015 06:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2505: -------------------------------- Fix Version/s: (was: 5.next) > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Affects Versions: 5.next > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Attachments: consoleText.txt > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 23 06:52:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 23 Sep 2015 06:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2505: -------------------------------- Affects Version/s: 5.next > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Affects Versions: 5.next > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Attachments: consoleText.txt > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 02:19:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 02:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2523) activemq artimes journal changes the package name In-Reply-To: References: Message-ID: Amos Feng created JBTM-2523: ------------------------------- Summary: activemq artimes journal changes the package name Key: JBTM-2523 URL: https://issues.jboss.org/browse/JBTM-2523 Project: JBoss Transaction Manager Issue Type: Bug Components: Application Server Integration Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next activemq-artimes upgrades from 1.0.0 to 1.1.0-wildfly-6 and the journal package name also changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 03:02:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 03:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2523) activemq artimes journal changes the package name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2523: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/917 > activemq artimes journal changes the package name > ------------------------------------------------- > > Key: JBTM-2523 > URL: https://issues.jboss.org/browse/JBTM-2523 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > activemq-artimes upgrades from 1.0.0 to 1.1.0-wildfly-6 and the journal package name also changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 04:50:01 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 04:50:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: Amos Feng created JBTM-2524: ------------------------------- Summary: CMRIntegrationTest failed with can not start the container Key: JBTM-2524 URL: https://issues.jboss.org/browse/JBTM-2524 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA, Testing Reporter: Amos Feng Assignee: Michael Musgrove http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt {code} Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 Sep 24, 2015 8:54:59 AM org.xnio.Xnio INFO: XNIO version 3.3.1.Final Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio INFO: XNIO NIO Implementation Version 3.3.1.Final Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl INFO: JBoss Remoting version 4.0.9.Final 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "messaging-activemq"), ("server" => "default"), ("http-connector" => "http-connector") ]) - failure description: "WFLYCTL0155: endpoint may not be null" {code} I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 04:54:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 04:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2525) Update to add a test for setting the use-journal-store in wildfly transaction susbystem In-Reply-To: References: Message-ID: Amos Feng created JBTM-2525: ------------------------------- Summary: Update to add a test for setting the use-journal-store in wildfly transaction susbystem Key: JBTM-2525 URL: https://issues.jboss.org/browse/JBTM-2525 Project: JBoss Transaction Manager Issue Type: Task Components: Application Server Integration, Testing Reporter: Amos Feng Assignee: Amos Feng Priority: Minor It could be useful to add a test in the CI script -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 05:19:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 24 Sep 2015 05:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112028#comment-13112028 ] Michael Musgrove commented on JBTM-2524: ---------------------------------------- This looks like a duplicate of JBTM-2520. Can you rebase your PR and retest. > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Michael Musgrove > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 05:19:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 24 Sep 2015 05:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2524: -------------------------------------- Assignee: Amos Feng (was: Michael Musgrove) > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 05:22:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 24 Sep 2015 05:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2522) Update performance comparison tests to use JMH In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112029#comment-13112029 ] Michael Musgrove commented on JBTM-2522: ---------------------------------------- Can you be more specific - my understanding of performance comparison tests is https://github.com/jbosstm/performance/tree/master/narayana/ArjunaJTA/jta/tests/classes/io/narayana/perf/product where we do a JMH run against other open source TMs > Update performance comparison tests to use JMH > ---------------------------------------------- > > Key: JBTM-2522 > URL: https://issues.jboss.org/browse/JBTM-2522 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 05:53:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 24 Sep 2015 05:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2519) Investigate if XTS and RTS work with enabled security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112047#comment-13112047 ] Gytis Trikleris commented on JBTM-2519: --------------------------------------- RTS tests in WildFly test suite work fine with security manager after adding a few permissions required by the test cases (not the implementation of RTS). However, XTS tests still fail because of missing permission to access XTS module jar. This happens after adding permissions required by the test cases. > Investigate if XTS and RTS work with enabled security manager > ------------------------------------------------------------- > > Key: JBTM-2519 > URL: https://issues.jboss.org/browse/JBTM-2519 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 06:02:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 24 Sep 2015 06:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2522) Update performance comparison tests to use JMH In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112055#comment-13112055 ] Gytis Trikleris commented on JBTM-2522: --------------------------------------- I meant https://github.com/jbosstm/performance/tree/master/comparison, but I'm not sure it's going to work. Is it possible to use JMH to test Arquillian tests? Or applications in WildFly deployed manually? > Update performance comparison tests to use JMH > ---------------------------------------------- > > Key: JBTM-2522 > URL: https://issues.jboss.org/browse/JBTM-2522 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 09:22:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 09:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112153#comment-13112153 ] Amos Feng commented on JBTM-2524: --------------------------------- no, I just rebase the PR and the failure still exists and it looks like the standalone-full.xml has changes again. see https://github.com/wildfly/wildfly/commit/5b470a7e824336d0b3cb5f5dba18f6a254c7dae0 The message-activemq subsystem template has some changes on the endpoint. > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 09:24:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 09:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112156#comment-13112156 ] Amos Feng commented on JBTM-2524: --------------------------------- So I suggest that it could avoid to use the static file but clone the standalone-full.xml and update to add the cmr config. Do you think it makes sense ? > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 09:25:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 24 Sep 2015 09:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112158#comment-13112158 ] Tom Jenkinson commented on JBTM-2524: ------------------------------------- I commented on the PR but the PR system should take care of a rebase in Narayana. Are you OK to make the changes required by that wildfly commit? Thanks, Tom > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 13:08:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 24 Sep 2015 13:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2523) activemq artimes journal changes the package name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2523: -------------------------------- Priority: Blocker (was: Major) > activemq artimes journal changes the package name > ------------------------------------------------- > > Key: JBTM-2523 > URL: https://issues.jboss.org/browse/JBTM-2523 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > activemq-artimes upgrades from 1.0.0 to 1.1.0-wildfly-6 and the journal package name also changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 21:26:01 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 21:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2524: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/918 > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 21:26:01 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 21:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2524: ---------------------------- Fix Version/s: 5.next > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 24 21:29:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 24 Sep 2015 21:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112370#comment-13112370 ] Amos Feng commented on JBTM-2524: --------------------------------- yeah, I send the PR to make the changes. I think it would be better to clone the standalone-full.xml and add the cmr configurations of ours. It will be useful when the wildfly changes the configuration in the next time. > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 05:22:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 25 Sep 2015 05:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2526) Create pre-release checking script In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2526: ------------------------------------- Summary: Create pre-release checking script Key: JBTM-2526 URL: https://issues.jboss.org/browse/JBTM-2526 Project: JBoss Transaction Manager Issue Type: Sub-task Components: Build System, Release Process Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next Write script to do tests, deprecation, and blockers checking before executing the release. There are example bash scripts for deprecation and tests checking already, but they should be merged into one and be configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 05:52:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 05:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2526) Create pre-release checking script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112446#comment-13112446 ] Tom Jenkinson commented on JBTM-2526: ------------------------------------- I think the deprecation script would be useful to print out the list of deprecated code and ask if its OK to continue. It is probably not worth doing the deprecation check for versions that do not match a pattern [0-9].\.0\.0\..* (i.e. no point in doing regression checks on minor/micro versions. > Create pre-release checking script > ---------------------------------- > > Key: JBTM-2526 > URL: https://issues.jboss.org/browse/JBTM-2526 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System, Release Process > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Write script to do tests, deprecation, and blockers checking before executing the release. > There are example bash scripts for deprecation and tests checking already, but they should be merged into one and be configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:02:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 25 Sep 2015 06:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2526) Create pre-release checking script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112454#comment-13112454 ] Gytis Trikleris commented on JBTM-2526: --------------------------------------- I was also thinking of adding the attribute to enable/disable failing of the build because of deprecation/test failure/blocker. In case you know them in advance, and you want to execute the script without interruptions. It would just print the warning in that case. But I'll add interactive confirmation as the default, in case the script is being run by the human. > Create pre-release checking script > ---------------------------------- > > Key: JBTM-2526 > URL: https://issues.jboss.org/browse/JBTM-2526 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System, Release Process > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Write script to do tests, deprecation, and blockers checking before executing the release. > There are example bash scripts for deprecation and tests checking already, but they should be merged into one and be configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:12:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2523) activemq artimes journal changes the package name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2523: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > activemq artimes journal changes the package name > ------------------------------------------------- > > Key: JBTM-2523 > URL: https://issues.jboss.org/browse/JBTM-2523 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > activemq-artimes upgrades from 1.0.0 to 1.1.0-wildfly-6 and the journal package name also changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2523) activemq artimes journal changes the package name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2523. ------------------------------- > activemq artimes journal changes the package name > ------------------------------------------------- > > Key: JBTM-2523 > URL: https://issues.jboss.org/browse/JBTM-2523 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.2.5.Final > > > activemq-artimes upgrades from 1.0.0 to 1.1.0-wildfly-6 and the journal package name also changes. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2526) Create pre-release checking script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2526: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Create pre-release checking script > ---------------------------------- > > Key: JBTM-2526 > URL: https://issues.jboss.org/browse/JBTM-2526 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System, Release Process > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Write script to do tests, deprecation, and blockers checking before executing the release. > There are example bash scripts for deprecation and tests checking already, but they should be merged into one and be configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2524: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2522) Update performance comparison tests to use JMH In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2522: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Update performance comparison tests to use JMH > ---------------------------------------------- > > Key: JBTM-2522 > URL: https://issues.jboss.org/browse/JBTM-2522 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2519) Investigate if XTS and RTS work with enabled security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2519: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Investigate if XTS and RTS work with enabled security manager > ------------------------------------------------------------- > > Key: JBTM-2519 > URL: https://issues.jboss.org/browse/JBTM-2519 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2512) Include BlackTie javadoc on Narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2512: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Include BlackTie javadoc on Narayana.io > --------------------------------------- > > Key: JBTM-2512 > URL: https://issues.jboss.org/browse/JBTM-2512 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2510) Provide some example jbossts-properties.xml on the narayana.io site In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2510: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Provide some example jbossts-properties.xml on the narayana.io site > ------------------------------------------------------------------- > > Key: JBTM-2510 > URL: https://issues.jboss.org/browse/JBTM-2510 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > This will mean we don't need to download the zip to use them (for say maven users). > We should provide: > local JTA > jacorb JTS > JDKORB JTS > IBMORB JTS -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2497) Update or remove references of HornetQ to Artemis In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2497: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Update or remove references of HornetQ to Artemis > ------------------------------------------------- > > Key: JBTM-2497 > URL: https://issues.jboss.org/browse/JBTM-2497 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie, Demonstrator, Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > There were reports of HornetQ still in at least the fooapp QS. We should try to remove references to the specific implementation unless necessary and in those cases use the correct name which is now Artemis. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2495) Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2495: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2495 > URL: https://issues.jboss.org/browse/JBTM-2495 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Documentation > Affects Versions: 5.0.0.M2 > Environment: RHEL 6.3 > Reporter: Joice Joy > Assignee: Amos Feng > Fix For: 5.next > > > I am installing Blacktie 5.2.2 Final with Wildfly 9.0.1 but the Wildfly server fails to start the Blacktie service > But the server does not start the blacktie service: > This is from quickstart quickstart/blacktie > > > > ========================================================================= > > > JBoss Bootstrap Environment > > > JBOSS_HOME: /fxtest/trep/wildfly/wildfly-9.0.1.Final > > > JAVA: /fxtest/trep/java/jdk1.8.0_51/bin/java > > > JAVA_OPTS: -server -XX:+UseCompressedOops -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE > > > ========================================================================= > > > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 > 07:35:52,490 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final > 07:35:52,892 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 07:35:53,007 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0049: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) starting > 07:35:55,053 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'job-repository-type' in the resource at address '/subsystem=batch' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,055 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,121 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment blacktie-admin-services-ear-5.2.2.Final.ear > 07:35:55,361 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 24) WFLYDR0001: Content added at location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:55,390 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 07:35:55,422 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final > 07:35:55,438 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.1.Final > 07:35:55,482 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.9.Final > 07:35:55,548 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > 07:35:55,554 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > 07:35:55,557 INFO [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 42) WFLYIIOP0001: Activating IIOP Subsystem > 07:35:55,602 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.4.Final) > 07:35:55,615 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > 07:35:55,652 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 07:35:55,661 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > 07:35:55,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0018: Started Driver service with driver-name = h2 > 07:35:55,827 INFO [org.jboss.as.security] (ServerService Thread Pool -- 59) WFLYSEC0002: Activating Security Subsystem > 07:35:55,829 INFO [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=4.9.2.Final > 07:35:55,849 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 07:35:55,849 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > 07:35:55,998 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,034 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,095 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 07:35:56,119 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 07:35:56,352 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path /fxtest/trep/wildfly/wildfly-9.0.1.Final/welcome-content > 07:35:56,417 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server. > 07:35:56,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > 07:35:56,589 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 07:35:56,945 INFO [org.wildfly.iiop.openjdk] (MSC service thread 1-3) WFLYIIOP0009: CORBA ORB Service started > 07:35:56,969 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 07:35:57,030 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/deployments > 07:35:57,059 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:57,187 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221000: live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingjournal,bindingsDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingbindings,largeMessagesDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messaginglargemessages,pagingDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingpaging) > 07:35:57,193 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221006: Waiting to obtain live lock > 07:35:57,287 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221012: Using AIO Journal > 07:35:57,387 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support CORE > 07:35:57,414 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Final > 07:35:57,439 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support AMQP > 07:35:57,443 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support STOMP > 07:35:57,502 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221034: Waiting to obtain live lock > 07:35:57,504 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221035: Live Server Obtained live lock > 07:35:58,108 INFO [org.jboss.messaging] (MSC service thread 1-3) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor acceptor > 07:35:58,112 INFO [org.jboss.messaging] (MSC service thread 1-1) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor-throughput acceptor > 07:35:58,206 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221007: Server is now live > 07:35:58,207 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221001: HornetQ Server version 2.4.7.Final (2.4.7.Final, 124) [9d12c6a3-4666-11e5-8632-95a54ac84561] > 07:35:58,210 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221003: trying to deploy queue jms.queue.ExpiryQueue > 07:35:58,514 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 66) WFLYMSG0002: Bound messaging object to jndi name java:/ConnectionFactory > 07:35:58,519 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 67) WFLYMSG0002: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory > 07:35:58,519 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 65) HQ221003: trying to deploy queue jms.queue.DLQ > 07:35:58,623 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0007: Registered connection factory java:/JmsXA > 07:35:58,721 INFO [org.hornetq.ra] (MSC service thread 1-4) HornetQ resource adaptor started > 07:35:58,721 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) IJ020002: Deployed: file://RaActivatorhornetq-ra > 07:35:58,733 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0002: Bound JCA ConnectionFactory [java:/JmsXA] > 07:35:58,733 INFO [org.jboss.as.messaging] (MSC service thread 1-4) WFLYMSG0002: Bound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-impl.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jsr173_1.0_api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,763 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry activation.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "blacktie-admin-services-5.2.2.Final.jar") > 07:35:58,885 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:98) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95) > ... 6 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment' > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89) > ... 6 more > > > 07:35:58,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "blacktie-admin-services-ear-5.2.2.Final.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"blacktie-admin-services-5.2.2.Final.jar\" of deployment \"blacktie-admin-services-ear-5.2.2.Final.ear\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment'"}} > 07:35:58,980 INFO [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name : "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:58,982 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > > > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 07:35:59,202 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 7156ms - Started 247 of 423 services (2 services failed or missing dependencies, 222 services are lazy, passive or on-demand) > 07:35:59,243 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: blacktie-admin-services-5.2.2.Final.jar) in 9ms > 07:35:59,332 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment blacktie-admin-services-ear-5.2.2.Final.ear (runtime-name: blacktie-admin-services-ear-5.2.2.Final.ear) in 98ms > 07:35:59,413 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0002: Content removed from location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:59,414 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:59,414 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2491) JTS and JacORB NS Docker images quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2491: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > JTS and JacORB NS Docker images quickstart > ------------------------------------------ > > Key: JBTM-2491 > URL: https://issues.jboss.org/browse/JBTM-2491 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a quickstart for JTS and JacORB Name Server Docker images. > Additionally, add Kubernetes pod configuration for that. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2492) Build and deploy Blacktie as part of BRP.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2492: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Build and deploy Blacktie as part of BRP.xml > -------------------------------------------- > > Key: JBTM-2492 > URL: https://issues.jboss.org/browse/JBTM-2492 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > We only update the Blacktie java artifacts so these should be able to be done from any machine: > {code} > call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" > build.bat -f blacktie\wildfly-blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml deploy -DskipTests > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2480: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2476) When a transaction times out, print the stack traces of the threads involved In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2476: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > When a transaction times out, print the stack traces of the threads involved > ---------------------------------------------------------------------------- > > Key: JBTM-2476 > URL: https://issues.jboss.org/browse/JBTM-2476 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Would be useful to help understand what the code was doing when the transaction times out. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2481) Automate NRP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2481: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Automate NRP > ------------ > > Key: JBTM-2481 > URL: https://issues.jboss.org/browse/JBTM-2481 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > There are a number of steps on NRP that could be automated using Jira API. > Lets try to do that: > https://community.jboss.org/wiki/NarayanaReleaseProcess -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2433) TransactionRolledBackException in MultiCloseTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2433: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > TransactionRolledBackException in MultiCloseTest > ------------------------------------------------ > > Key: JBTM-2433 > URL: https://issues.jboss.org/browse/JBTM-2433 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > Attachments: com.arjuna.wstx.tests.arq.ba.MultiCloseTest-output.txt > > > It looks like this failure has been caused by the race condition in WS-BA. In our tests it should be handled by the Byteman rule, but seems that for an unknown reason it has still failed in this occasion. > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.ba.MultiCloseTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.117 sec <<< FAILURE! > testMultiClose(com.arjuna.wstx.tests.arq.ba.MultiCloseTest) Time elapsed: 2.5 sec <<< ERROR! > com.arjuna.wst.TransactionRolledBackException: null > at com.arjuna.wst11.stub.BusinessActivityTerminatorStub.close(BusinessActivityTerminatorStub.java:95) > at com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple.close(UserBusinessActivityImple.java:157) > at com.arjuna.wstx.tests.arq.ba.MultiCloseTest.testMultiClose(MultiCloseTest.java:71) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2458: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2234) out of memory when logging more messages than heap size (surefire issue) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2234: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > out of memory when logging more messages than heap size (surefire issue) > ------------------------------------------------------------------------ > > Key: JBTM-2234 > URL: https://issues.jboss.org/browse/JBTM-2234 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.0.2 > Environment: JTS testing > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Optional > Fix For: 5.next > > > Running com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 on JacORB with about 500000 transactions results in an OOM error because surefire keeps in logs in memory until the test has finished. > In this particular test jacorb logs messages at INFO level for each transaction resulting in excessive memory requirements. We can't make the heap too large because the default JVM is 32 bit. However, we could fix it by reducing the jacorb log level to WARN. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Use Project Atomic for docker image(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2298: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Use Project Atomic for docker image(s) > -------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS, REST, XTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2409: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > Attachments: 32287.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2206: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2120) Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2120: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2120 > URL: https://issues.jboss.org/browse/JBTM-2120 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Pull https://github.com/jbosstm/narayana/pull/598 added deferred throwables in case the XAR::end fails during commit. It doesn't handle the case of the HEURISTIC_ROLLBACK of a first resource where Narayana rolls back the remaining participants and then clears the failed/heuristic lists (and marks the txn as rolled back). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2180) Determine whether or not we should use a specific collections framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2180: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Determine whether or not we should use a specific collections framework > ----------------------------------------------------------------------- > > Key: JBTM-2180 > URL: https://issues.jboss.org/browse/JBTM-2180 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA, JTS, Performance Testing, REST, Transaction Core > Affects Versions: 5.0.1 > Reporter: Mark Little > Assignee: Tom Jenkinson > Priority: Optional > Fix For: 5.next > > > We use many of the inbuilt collections implementations (such as Hashtable) which are well known to be suboptimal in certain cases. Should we use a separate collections framework, e.g., https://github.com/goldmansachs/gs-collections > There are pros and cons of doing this. But first we need to determine whether it really makes sense from a performance perspective. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2203: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2115: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2110: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1804: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1340) BeanPopulator overhead needs looking into In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1340: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > BeanPopulator overhead needs looking into > ----------------------------------------- > > Key: JBTM-1340 > URL: https://issues.jboss.org/browse/JBTM-1340 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Common > Affects Versions: 4.17.2 > Environment: Mac OS 10.7 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.next > > > During profiling, BeanPopulator can represent a 7% overhead. It may not seem like a lot, but for something as relatively simple as what BeanPopulator should be doing, it seems to be quite a bit. > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.coordinator.TxStats.enabled > 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance > 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance > 2.5% - 1,587 ms - 10,000 inv. java.lang.StringBuilder. > 2.3% - 1,507 ms - 10,000 inv. java.lang.StringBuilder.toString > 0.0% - 320 ?s - 10,000 inv. java.util.concurrent.ConcurrentMap.containsKey > 0.0% - 61 ?s - 10,000 inv. java.lang.Class.getName > 0.0% - 25 ?s - 10,000 inv. java.util.concurrent.ConcurrentMap.get -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:44:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1854: -------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:45:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-855) Create an example showing integration with Spring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-855: ------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Create an example showing integration with Spring > ------------------------------------------------- > > Key: JBTM-855 > URL: https://issues.jboss.org/browse/JBTM-855 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > Original Estimate: 1 week > Remaining Estimate: 1 week > > The main thing is to show the config but we need to provide an example that shows how to ensure the XAResources are available for recovery -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 06:45:01 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 06:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-741) Remove redundant XTS classes and code paths identified from coverage data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-741: ------------------------------- Fix Version/s: 5.next (was: 5.2.5.Final) > Remove redundant XTS classes and code paths identified from coverage data > ------------------------------------------------------------------------- > > Key: JBTM-741 > URL: https://issues.jboss.org/browse/JBTM-741 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 4.11.0 > Reporter: Andrew Dinn > Assignee: Gytis Trikleris > Fix For: 5.next > > > Coverage analysis of the XTS code base has idenitifed a lot of unexercised classes and code paths. These need pruning in order to simplify maintenance and testing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 08:56:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 25 Sep 2015 08:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2524: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 09:05:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 09:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2524: -------------------------------- Fix Version/s: 5.2.5.Final (was: 5.next) > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.2.5.Final > > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 25 09:05:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 25 Sep 2015 09:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2524) CMRIntegrationTest failed with can not start the container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2524. ------------------------------- > CMRIntegrationTest failed with can not start the container > ---------------------------------------------------------- > > Key: JBTM-2524 > URL: https://issues.jboss.org/browse/JBTM-2524 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.2.5.Final > > > http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-jdk8/PROFILE=MAIN,jdk=jdk8.latest,label=linux/1220/artifact/ArjunaJTA/jta/target/surefire-reports/com.hp.mwtests.ts.jta.commitmarkable.integration.CMRIntegrationTest-output.txt > {code} > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0 > Sep 24, 2015 8:54:59 AM org.xnio.Xnio > INFO: XNIO version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.xnio.nio.NioXnio > INFO: XNIO NIO Implementation Version 3.3.1.Final > Sep 24, 2015 8:55:00 AM org.jboss.remoting3.EndpointImpl > INFO: JBoss Remoting version 4.0.9.Final > 08:55:01,492 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final > 08:55:02,403 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 08:55:02,728 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 2.0.0.CR4 "Kenny" starting > 08:55:06,434 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 17) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 08:55:06,456 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 20) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("http-connector" => "http-connector") > ]) - failure description: "WFLYCTL0155: endpoint may not be null" > {code} > I think we need to avoid to using the static ArjunaJTA/jta/src/test/resources/standalone-cmr.xml and try to clone the jboss-as/standalone/configuration/standalone-full.xml with adding the cmr configs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 28 04:52:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 28 Sep 2015 04:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112776#comment-13112776 ] Michael Musgrove commented on JBTM-2505: ---------------------------------------- Im still seeing it > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Affects Versions: 5.2.5.Final > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Attachments: consoleText.txt > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 08:51:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 29 Sep 2015 08:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reassigned JBTM-1854: ------------------------------------- Assignee: Michael Musgrove (was: Gytis Trikleris) > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 09:21:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Sep 2015 09:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2206: -------------------------------- Priority: Minor (was: Major) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 09:21:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Sep 2015 09:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2409: -------------------------------- Priority: Minor (was: Major) > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > Attachments: 32287.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 09:21:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Sep 2015 09:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2409: -------------------------------- Priority: Major (was: Minor) > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > Attachments: 32287.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 09:21:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Sep 2015 09:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2492) Build and deploy Blacktie as part of BRP.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2492: -------------------------------- Priority: Minor (was: Major) > Build and deploy Blacktie as part of BRP.xml > -------------------------------------------- > > Key: JBTM-2492 > URL: https://issues.jboss.org/browse/JBTM-2492 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > We only update the Blacktie java artifacts so these should be able to be done from any machine: > {code} > call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" > build.bat -f blacktie\wildfly-blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml install -DskipTests > build.bat -f blacktie\pom.xml deploy -DskipTests > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 09:49:00 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Sep 2015 09:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2505) Java heap space issue on Brandon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113325#comment-13113325 ] Tom Jenkinson commented on JBTM-2505: ------------------------------------- Temporarily disabled Brandon > Java heap space issue on Brandon > -------------------------------- > > Key: JBTM-2505 > URL: https://issues.jboss.org/browse/JBTM-2505 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Affects Versions: 5.2.5.Final > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Attachments: consoleText.txt > > > narayana-AS800 build fails whenever it runs on Brandon due to not enough java heap space. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 13:14:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 29 Sep 2015 13:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1854: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/919 > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 13:19:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 29 Sep 2015 13:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113443#comment-13113443 ] Michael Musgrove commented on JBTM-1854: ---------------------------------------- The issue is that the hornetq qa tests run under the control of ExecutionWrapper which initialises the orb and then calls the Main class of the server. But the Main class also initialised an orb. The result is that incoming CORBA requests (to the server) set up the PICurrent object corresponding to the orb created by the ExecutionWrapper with the transaction propagation context but the server is using a different PICurrent (since it is using a different orb). > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 23:05:00 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 29 Sep 2015 23:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2527) Update to check the buffer size in btgetattribute In-Reply-To: References: Message-ID: Amos Feng created JBTM-2527: ------------------------------- Summary: Update to check the buffer size in btgetattribute Key: JBTM-2527 URL: https://issues.jboss.org/browse/JBTM-2527 Project: JBoss Transaction Manager Issue Type: Enhancement Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Priority: Minor Fix For: 5.later currently the nbf btgetattribute does not check the buffer size is big enough for copying the value. So it should return error if the pass buffer size is not enough. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 06:30:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 30 Sep 2015 06:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2528) QA testsuite needs documenting In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2528: -------------------------------------- Summary: QA testsuite needs documenting Key: JBTM-2528 URL: https://issues.jboss.org/browse/JBTM-2528 Project: JBoss Transaction Manager Issue Type: Task Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later We need a document detailing what the tests in the QA testsuite test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 06:31:00 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 30 Sep 2015 06:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2528) QA testsuite needs documenting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2528: ----------------------------------- Component/s: Documentation > QA testsuite needs documenting > ------------------------------ > > Key: JBTM-2528 > URL: https://issues.jboss.org/browse/JBTM-2528 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > We need a document detailing what the tests in the QA testsuite test. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 09:35:00 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 30 Sep 2015 09:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2519) Investigate if XTS and RTS work with enabled security manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2519: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/920 > Investigate if XTS and RTS work with enabled security manager > ------------------------------------------------------------- > > Key: JBTM-2519 > URL: https://issues.jboss.org/browse/JBTM-2519 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 30 10:00:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 30 Sep 2015 10:00:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1854) Journal failures in CI test suite on JDKORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1854: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Journal failures in CI test suite on JDKORB > ------------------------------------------- > > Key: JBTM-1854 > URL: https://issues.jboss.org/browse/JBTM-1854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: CurrentTests01_Test036.tar.gz, idlj-failures.tar.gz, testoutput.idlj.tar.run4.gz > > > The first CI job link includes: > CurrentTests01_Test036 > jtsremote JTSRemote_ImplicitPropagationTest > crashrecovery02_2 CrashRecovery02_2 - all of them > crashrecovery05_1 CrashRecovery05_1 Tests 1, 6, 7, 8, 9, 10 > crashrecovery12 CrashRecovery12_Test03 (55 failures - about half of them) > The second CI job link includes: > JTSRemote_ImplicitPropagationTest failure > CrashRecovery02_2_Test46 hang -- This message was sent by Atlassian JIRA (v6.4.11#64026)