From issues at jboss.org Mon Sep 1 04:59:59 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 1 Sep 2014 04:59:59 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2181) OptionalJaxWSTxInboundBridgeHandler does not handle multi-threaded requests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2181: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > OptionalJaxWSTxInboundBridgeHandler does not handle multi-threaded requests > --------------------------------------------------------------------------- > > Key: JBTM-2181 > URL: https://issues.jboss.org/browse/JBTM-2181 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: TxBridge > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 05:00:59 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 1 Sep 2014 05:00:59 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2246) TXBridge multi-hop quickstart fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris resolved JBTM-2246. ----------------------------------- Resolution: Done > TXBridge multi-hop quickstart fails > ----------------------------------- > > Key: JBTM-2246 > URL: https://issues.jboss.org/browse/JBTM-2246 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: TxBridge, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana-quickstarts/104/ > {code} > 07:09:30,301 ERROR [org.jboss.as.txn] (default task-9) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0 > 07:09:30,301 ERROR [org.jboss.as.txn] (default task-9) WFLYTX0001: Unable to roll back active transaction: com.arjuna.ats.jta.exceptions.InvalidTerminationStateException > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple.rollbackAndDisassociate(TransactionImple.java:358) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: 40a71)] > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: 40a71)] > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:114) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$1.tearDown(UndertowDeploymentInfoService.java:1470) > at io.undertow.servlet.core.CompositeThreadSetupAction$1.tearDown(CompositeThreadSetupAction.java:52) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:311) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 05:19:00 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 1 Sep 2014 05:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2218) testSuspendResume(org.jboss.narayana.compensations.functional.compensationScoped.CompensationScopedTestRemote) failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997318#comment-12997318 ] Gytis Trikleris commented on JBTM-2218: --------------------------------------- Leaving only one failure in the CI provided in the description > testSuspendResume(org.jboss.narayana.compensations.functional.compensationScoped.CompensationScopedTestRemote) failed > --------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2218 > URL: https://issues.jboss.org/browse/JBTM-2218 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: TXFramework > Affects Versions: 5.0.2 > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.0.4 > > > Failing everywhere: > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-codeCoverage/127/console > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/182/console > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/PROFILE=XTS,jdk=jdk7.latest,label=linux/575/console > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/578/ -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 05:19:00 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 1 Sep 2014 05:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2218) testSuspendResume(org.jboss.narayana.compensations.functional.compensationScoped.CompensationScopedTestRemote) failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2218: ---------------------------------- Description: http://172.17.131.2/view/Status/job/narayana/575/PROFILE=XTS,jdk=jdk7.latest,label=linux/ (was: Failing everywhere: http://172.17.131.2/view/Narayana+BlackTie/job/narayana-codeCoverage/127/console http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/182/console http://172.17.131.2/view/Narayana+BlackTie/job/narayana/PROFILE=XTS,jdk=jdk7.latest,label=linux/575/console http://172.17.131.2/view/Narayana+BlackTie/job/narayana/578/) > testSuspendResume(org.jboss.narayana.compensations.functional.compensationScoped.CompensationScopedTestRemote) failed > --------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2218 > URL: https://issues.jboss.org/browse/JBTM-2218 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: TXFramework > Affects Versions: 5.0.2 > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/575/PROFILE=XTS,jdk=jdk7.latest,label=linux/ -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 05:24:59 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 1 Sep 2014 05:24:59 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2228) HotelBookingTest#testSuccess fails because of missing transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997320#comment-12997320 ] Gytis Trikleris commented on JBTM-2228: --------------------------------------- Leaving only one CI failure provided in the description > HotelBookingTest#testSuccess fails because of missing transaction > ----------------------------------------------------------------- > > Key: JBTM-2228 > URL: https://issues.jboss.org/browse/JBTM-2228 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana-quickstarts/93 > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelBookingTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.894 sec <<< FAILURE! > testSuccess(org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelBookingTest) Time elapsed: 0.502 sec <<< ERROR! > java.lang.NullPointerException > at org.jboss.narayana.compensations.impl.CompensationManagerImpl.setCompensateOnly(CompensationManagerImpl.java:39) > at org.jboss.narayana.compensations.impl.CompensationInterceptorBase.handleException(CompensationInterceptorBase.java:94) > at org.jboss.narayana.compensations.impl.CompensationInterceptorBase.invokeInCallerTx(CompensationInterceptorBase.java:74) > at org.jboss.narayana.compensations.impl.CompensationInterceptorRequired.intercept(CompensationInterceptorRequired.java:46) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) > at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelBookingClient$Proxy$_$$_WeldSubclass.makeBooking(Unknown Source) > at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelBookingTest.testSuccess(HotelBookingTest.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > 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:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > 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.junit.runner.JUnitCore.run(JUnitCore.java:157) > at org.junit.runner.JUnitCore.run(JUnitCore.java:136) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:160) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:126) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:90) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:243) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:230) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:149) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > {code} > {code} > [0m06:06:42,113 ERROR [org.jboss.as.webservices] (default task-11) WFLYWS0056: Method invocation failed with exception: Transaction is required for invocation: org.jboss.narayana.compensations.api.TransactionalException: Transaction is required for invocation > at org.jboss.narayana.compensations.impl.CompensationInterceptorMandatory.intercept(CompensationInterceptorMandatory.java:46) [txframework-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelServiceImpl$Proxy$_$$_WeldSubclass.makeBooking(Unknown Source) [test.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:49) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:130) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:104) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:237) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:69) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.3.0.Final.jar:2.3.0.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:243) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:230) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:149) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.narayana.compensations.api.TransactionRequiredException > ... 91 more > 06:06:42,173 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-11) Application {http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}HotelServiceService#{http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}makeBooking has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Transaction is required for invocation > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:170) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:272) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:136) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:237) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:69) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:107) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.3.0.Final.jar:2.3.0.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:243) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:230) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:149) [undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) [undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.narayana.compensations.api.TransactionalException: Transaction is required for invocation > at org.jboss.narayana.compensations.impl.CompensationInterceptorMandatory.intercept(CompensationInterceptorMandatory.java:46) [txframework-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.1.Final.jar:2014-05-09 12:21] > at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelServiceImpl$Proxy$_$$_WeldSubclass.makeBooking(Unknown Source) [test.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:49) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:130) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:104) > ... 46 more > Caused by: org.jboss.narayana.compensations.api.TransactionRequiredException > ... 91 more > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 07:49:00 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 1 Sep 2014 07:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2196) QA suite failure: CrashRecovery05_2_Test034 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2196: ----------------------------------- Attachment: CrashRecovery05_2_Test034.tar > QA suite failure: CrashRecovery05_2_Test034 > ------------------------------------------- > > Key: JBTM-2196 > URL: https://issues.jboss.org/browse/JBTM-2196 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.0.4 > > Attachments: CrashRecovery05_2_Test034.tar > > > http://172.17.131.2/view/Status/job/narayana/550/PROFILE=QA_JTS_JACORB,jdk=jdk7.latest,label=linux -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 12:46:00 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 1 Sep 2014 12:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1453) Reinstate/review the numbers to detect performance regressions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997544#comment-12997544 ] Michael Musgrove commented on JBTM-1453: ---------------------------------------- I am in the process of porting the tests over to JMH (http://openjdk.java.net/projects/code-tools/jmh/) which is a more predictable micro benchmarking platform. I am also in the process of moving the tests to our performance repo (https://github.com/jbosstm/performance). > Reinstate/review the numbers to detect performance regressions > -------------------------------------------------------------- > > Key: JBTM-1453 > URL: https://issues.jboss.org/browse/JBTM-1453 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Performance Testing > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.0.4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 1 15:08:00 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 1 Sep 2014 15:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2242: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/717, https://github.com/jbosstm/narayana/pull/718 (was: https://github.com/jbosstm/narayana/pull/717) > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 07:20:00 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 2 Sep 2014 07:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997739#comment-12997739 ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1133346|https://bugzilla.redhat.com/show_bug.cgi?id=1133346] from NEW to ASSIGNED > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 07:20:00 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 2 Sep 2014 07:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2238) Tooling does not expose CMR records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997740#comment-12997740 ] RH Bugzilla Integration commented on JBTM-2238: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1113225|https://bugzilla.redhat.com/show_bug.cgi?id=1113225] from NEW to ASSIGNED > Tooling does not expose CMR records > ----------------------------------- > > Key: JBTM-2238 > URL: https://issues.jboss.org/browse/JBTM-2238 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tooling > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > CMR resources are not being exposed as MBeans via the (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser) tooling. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 09:51:01 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Sep 2014 09:51:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1369) Benchmark performance difference between JacORB and JDK ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-1369. ------------------------------------ Resolution: Done h2. Executive Summary: Throughput for the sun orb is 2.5x faster than JacORB (1084 versus 453 distributed transactions/sec) Slightly more detailed Summary: h2. ORB transport comparison: This test compares JTS performance using 2 different orbs (JacORB and the sun JDK orb). The sun orb is the standard one bundled in the Oracle jdk and JacORB is the one we ship in product: * sun orb: Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) * jacorb: 2.3.2-jbossorg-5 (which I presume maps on to JacORB 2.3) The test config runs a client and server in separate JVMs and uses explicit (OTS) transaction propagation to update a variable in a remote CORBA object (so the test uses the 1PC optimization). The figures show that throughput for the sun orb is 2.5x faster than JacORB: {quote} 2014-05-14 23:11:29,939 out: Test performance (for orb type JAVAIDL): 1084 calls/sec (200000 invocations using 50 threads with 0 errors. Total time 184399 ms) 2014-05-14 23:19:24,591 out: Test performance (for orb type JACORB): 453 calls/sec (200000 invocations using 50 threads with 0 errors. Total time 440744 ms) {quote} h3. Remark: We also ran on a version of the IMB orb (IBM J9 VM build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References 20140106_181350 (JIT enabled, AOT enabled)) but do note that we have not yet got recovery working with this orb so the following figure is provisional (IBM orb being 4x faster than JacORB): {quote} 2014-05-14 22:43:50,588 out: Test performance (for orb type IBMORB): 1622 calls/sec (300000 invocations using 50 threads with 0 errors. Total time 184924 ms) {quote} Also noteworthy is that we have a job running the benchmark using narayana master. > Benchmark performance difference between JacORB and JDK ORB > ----------------------------------------------------------- > > Key: JBTM-1369 > URL: https://issues.jboss.org/browse/JBTM-1369 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTS, Performance Testing > Affects Versions: 4.17.0 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > JBTM-934 added support for the JDK orb to JTS. IOR sizes can range in size from 512 bytes to entirely unbounded, with the ORB being able to add arbitrary data within specific portions. Since the IOR is packed into transaction logs and if the IOR sizes are significantly different we may find that transaction throughput has been improved or degraded. We should run some benchmarks to see what the impact is. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 12:25:00 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Tue, 2 Sep 2014 12:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: Sergey Shilin created JBTM-2247: ----------------------------------- Summary: Memory leak in TransactionImple Key: JBTM-2247 URL: https://issues.jboss.org/browse/JBTM-2247 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Sergey Shilin Assignee: Tom Jenkinson Priority: Critical There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. HashTable _duplicateResources contains of 6 millions of objects and takes 2.8Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 12:27:00 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Tue, 2 Sep 2014 12:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shilin updated JBTM-2247: -------------------------------- Description: There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? was: There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. HashTable _duplicateResources contains of 6 millions of objects and takes 2.8Gb of memory. Is there any patches or solutions for this problem? > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 12:29:59 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Tue, 2 Sep 2014 12:29:59 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shilin updated JBTM-2247: -------------------------------- Attachment: OOM-jboss-1.JPG OOM-jboss-2.JPG > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 12:51:00 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Sep 2014 12:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997987#comment-12997987 ] Michael Musgrove commented on JBTM-2247: ---------------------------------------- Please will you update the report with the following items: * attach your hprof file; * update the Affects Version field of the bug report so that we know where to look in the sources. > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 13:59:00 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Tue, 2 Sep 2014 13:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998027#comment-12998027 ] Sergey Shilin commented on JBTM-2247: ------------------------------------- * heapdump link: https://www.dropbox.com/s/e39026tdvhwlcqs/java_pid27462.hprof.gz?dl=0 * jboss version 7.1.1 > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 05:24:01 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 3 Sep 2014 05:24:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2121) Add a jdbc object store implementation for later revisions of MySQL driver In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998253#comment-12998253 ] RH Bugzilla Integration commented on JBTM-2121: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1097166|https://bugzilla.redhat.com/show_bug.cgi?id=1097166] from NEW to CLOSED > Add a jdbc object store implementation for later revisions of MySQL driver > -------------------------------------------------------------------------- > > Key: JBTM-2121 > URL: https://issues.jboss.org/browse/JBTM-2121 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 4.17.17, 5.0.1 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.20, 5.0.2 > > > commit 44553931 updated the MySQl driver to 5.1.28. > In this revision of the driver, it is reporting as mysql, not mysql_ab. It should be possible to duplicate our mysql_ab_driver to mysql_driver in order to catch both cases. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 08:21:00 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Wed, 3 Sep 2014 08:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shilin updated JBTM-2247: -------------------------------- Affects Version/s: 4.16.2 > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 08:24:00 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Wed, 3 Sep 2014 08:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998027#comment-12998027 ] Sergey Shilin edited comment on JBTM-2247 at 9/3/14 8:23 AM: ------------------------------------------------------------- * heapdump link: https://www.dropbox.com/s/e39026tdvhwlcqs/java_pid27462.hprof.gz?dl=0 * jboss version 7.2.0 was (Author: true_pk): * heapdump link: https://www.dropbox.com/s/e39026tdvhwlcqs/java_pid27462.hprof.gz?dl=0 * jboss version 7.1.1 > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 08:27:00 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Wed, 3 Sep 2014 08:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998027#comment-12998027 ] Sergey Shilin edited comment on JBTM-2247 at 9/3/14 8:26 AM: ------------------------------------------------------------- * heapdump link: https://www.dropbox.com/s/e39026tdvhwlcqs/java_pid27462.hprof.gz?dl=0 * jboss version 7.2.0 * jboss eap 6.1Final was (Author: true_pk): * heapdump link: https://www.dropbox.com/s/e39026tdvhwlcqs/java_pid27462.hprof.gz?dl=0 * jboss version 7.2.0 > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 08:29:01 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Wed, 3 Sep 2014 08:29:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998354#comment-12998354 ] Sergey Shilin commented on JBTM-2247: ------------------------------------- Please, watch the ticket ASAP. It is very important for out product. > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 10:09:01 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Wed, 3 Sep 2014 10:09:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shilin updated JBTM-2247: -------------------------------- Component/s: JTA > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 3 13:05:01 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 3 Sep 2014 13:05:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998519#comment-12998519 ] Michael Musgrove commented on JBTM-2247: ---------------------------------------- It looks like all of the memory is in use by a single transaction. Is it possible that you have a long running transaction that is doing many ejb calls (where each call enlists a duplicate resource) and never terminates the transaction (the suspect thread is http-qaapp029cn.netcracker.com/10.112.2.58:6550-3). > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 05:59:00 2014 From: issues at jboss.org (Sergey Shilin (JIRA)) Date: Thu, 4 Sep 2014 05:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998782#comment-12998782 ] Sergey Shilin commented on JBTM-2247: ------------------------------------- {quote} never terminates the transaction {quote} Michael, it is not really so because the problem doesn't appear with fewer amount of ejb calls. With 5000 it works, with 7000 it doesn't work. > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 06:02:00 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 4 Sep 2014 06:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2248) Sansa doesn't have Ant installed In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2248: ------------------------------------- Summary: Sansa doesn't have Ant installed Key: JBTM-2248 URL: https://issues.jboss.org/browse/JBTM-2248 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing Reporter: Gytis Trikleris Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.0.4 Jenkins node Sansa does not have Ant installed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 06:08:00 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 4 Sep 2014 06:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2249) Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2249: ------------------------------------- Summary: Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security Key: JBTM-2249 URL: https://issues.jboss.org/browse/JBTM-2249 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: BlackTie Reporter: Gytis Trikleris Assignee: Amos Feng Fix For: 5.0.4 http://172.17.131.2/view/Status/job/narayana/631/ {code} [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build (server-provisioning) on project wildfly-blacktie-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip modules: Could not resolve module resource artifact ${org.apache.cxf:cxf-rt-ws-security?jandex} for feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip -> {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 06:23:00 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 4 Sep 2014 06:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998798#comment-12998798 ] Michael Musgrove commented on JBTM-2247: ---------------------------------------- What do you mean by it works - the issue you have reported is that there are so many outstanding resource enlistments that the JVM runs out of memory. Note that this is not a leak in the transaction manager since we are doing what is requested (ie enlisting a resource on each ejb call - the reason we have to store duplicates is that the spec says we need to make the corresponding delist call come commit time). As far as can see, you have 2 options, either increase your heap size or restructure things to avoid making thousands of calls within the same transaction. > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 07:07:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 4 Sep 2014 07:07:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998810#comment-12998810 ] Michael Musgrove commented on JBTM-2247: ---------------------------------------- Can you verify that ejb calls you are making are using resources (it looks like you are using JMS from the thread dump) so that we can identify where the resource enlistments are coming from? > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 07:45:00 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 4 Sep 2014 07:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998827#comment-12998827 ] Mark Little commented on JBTM-2247: ----------------------------------- Agree with Mike: doesn't look or behave like a memory leak issue within the TM. Any chance you can send us a stand-alone example which we can run to show the problem? > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 07:48:01 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 4 Sep 2014 07:48:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998828#comment-12998828 ] Mark Little commented on JBTM-2247: ----------------------------------- You also say this is affecting your product and running EAP 6.1 Final. I therefore assume you've got a supported version and the best route to take would be to go through the Support Portal rather than the public forums, which are best-effort only. > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 09:52:00 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Sep 2014 09:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2248) Sansa doesn't have Ant installed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2248. --------------------------------- Fix Version/s: (was: 5.0.4) Resolution: Done Done > Sansa doesn't have Ant installed > -------------------------------- > > Key: JBTM-2248 > URL: https://issues.jboss.org/browse/JBTM-2248 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > > Jenkins node Sansa does not have Ant installed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 00:20:00 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 5 Sep 2014 00:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2249) Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2249: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/720 > Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security > ------------------------------------------------------------------------------- > > Key: JBTM-2249 > URL: https://issues.jboss.org/browse/JBTM-2249 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/631/ > {code} > [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build (server-provisioning) on project wildfly-blacktie-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip modules: Could not resolve module resource artifact ${org.apache.cxf:cxf-rt-ws-security?jandex} for feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip -> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 00:20:00 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 5 Sep 2014 00:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2249) Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999169#comment-12999169 ] Amos Feng commented on JBTM-2249: --------------------------------- It dues to the wildfly build-tools upgrade. > Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security > ------------------------------------------------------------------------------- > > Key: JBTM-2249 > URL: https://issues.jboss.org/browse/JBTM-2249 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/631/ > {code} > [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build (server-provisioning) on project wildfly-blacktie-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip modules: Could not resolve module resource artifact ${org.apache.cxf:cxf-rt-ws-security?jandex} for feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip -> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 05:34:59 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 5 Sep 2014 05:34:59 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2249) Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2249: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Blackie subsystem build fails because of missing org.apache.cxf:cxf-rt-security > ------------------------------------------------------------------------------- > > Key: JBTM-2249 > URL: https://issues.jboss.org/browse/JBTM-2249 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/631/ > {code} > [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build (server-provisioning) on project wildfly-blacktie-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha2:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip modules: Could not resolve module resource artifact ${org.apache.cxf:cxf-rt-ws-security?jandex} for feature pack /home/hudson/.m2/repository/org/wildfly/wildfly-feature-pack/9.0.0.Alpha1-SNAPSHOT/wildfly-feature-pack-9.0.0.Alpha1-SNAPSHOT.zip -> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 08:19:00 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 5 Sep 2014 08:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2247) Memory leak in TransactionImple In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2247. ------------------------------- Resolution: Rejected Hi Sergey, I am going to close this issue and as Mark has already suggested, I too would recommend opening a support case for your issue. With more detail it appears as though EJB is enlisting many XAResources with the same transaction. As Mike says, we maintain the list of duplicates for spec compliance reasons. Although the EJB usage is legal it may still be possible to optimize that aspect of the system to avoid duplicate registration. I believe it registers the XAR in order to propagate certain information to remote servers in the case where the application requires that behaviour. If you are not using multiple servers it may be possible that EJB would not require its XAR registering at all. So I do not believe this to be a bug in JBTM, hence why I have to close the issue here. I am sure your report will assist the support engineer responsible as it was very helpful to diagnose the issue so far. Thanks again, Tom > Memory leak in TransactionImple > ------------------------------- > > Key: JBTM-2247 > URL: https://issues.jboss.org/browse/JBTM-2247 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.16.2 > Reporter: Sergey Shilin > Assignee: Tom Jenkinson > Priority: Critical > Attachments: OOM-jboss-1.JPG, OOM-jboss-2.JPG > > > There is a problem in com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple. > HashTable _duplicateResources contains of 6 millions of objects and takes 2Gb of memory. Is there any patches or solutions for this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 04:12:00 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 8 Sep 2014 04:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2242: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Both PRs passed > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 07:33:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Sep 2014 07:33:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2208) Removed unused method from ActionManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001321#comment-13001321 ] Michael Musgrove commented on JBTM-2208: ---------------------------------------- We cannot change the semantics of the getTimeAdded (by calling currentTimeMillis lazily or returning a fake value) since any user of this API method will be doing so because he wants to know when the action was added. I have marked the method as Depecated and will remove in a subsequent release. > Removed unused method from ActionManager > ---------------------------------------- > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 07:34:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Sep 2014 07:34:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2208) Removed unused method from ActionManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2208: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/676, https://github.com/jesperpedersen/narayana/pull/1 (was: https://github.com/jbosstm/narayana/pull/676) > Removed unused method from ActionManager > ---------------------------------------- > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 07:36:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Sep 2014 07:36:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2208) Removed unused method from ActionManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001322#comment-13001322 ] Michael Musgrove commented on JBTM-2208: ---------------------------------------- I updated the Git Pull Request field with a PR on jespers branch that backs out his changes and marks the method Deprecated/deprecated. > Removed unused method from ActionManager > ---------------------------------------- > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 08:12:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Sep 2014 08:12:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2207) Make default name null in order for quick lookup in BeanPopulator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001345#comment-13001345 ] Michael Musgrove commented on JBTM-2207: ---------------------------------------- StringBuilder is more efficient at concatenating strings in both time and space and I do see a lot of calls in our code base to getNamedInstance so my preference is to go ahead with this proposed change. > Make default name null in order for quick lookup in BeanPopulator > ----------------------------------------------------------------- > > Key: JBTM-2207 > URL: https://issues.jboss.org/browse/JBTM-2207 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 08:17:20 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 11 Sep 2014 08:17:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2207) Make default name null in order for quick lookup in BeanPopulator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001351#comment-13001351 ] Tom Jenkinson commented on JBTM-2207: ------------------------------------- I have no objections either, I will merge it. > Make default name null in order for quick lookup in BeanPopulator > ----------------------------------------------------------------- > > Key: JBTM-2207 > URL: https://issues.jboss.org/browse/JBTM-2207 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 15:22:20 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Sep 2014 15:22:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2209) Use Deque for ThreadActionData In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001605#comment-13001605 ] Michael Musgrove commented on JBTM-2209: ---------------------------------------- OK I have added a bit of asbestos to the fireguard ;-) and created 2 JMH benchmarks for comparing the use of Stack versus Deque in ThreadActionData. My findings are: * with benchmark 1 Deque gives an 3.8% (5.8%) improvement using 1 (10) threads * with benchmark 2 Deque gives an 3.8% (4.6%) improvement using 1 (10) threads I ran each benchmark on my laptop for 5 mins (running each test twice using either 1 or 10 threads to do the work on my quad core laptop (with a 1s warmup). I watched the CPU usage to ensure that it was roughly constant (100% for the 1 thread test and about 400% for the 10 thread test). I think this is good enough to accept the PR. The actual benchmark is: https://github.com/mmusgrov/performance/blob/JBTM-1453/narayana/ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/atomicaction/CheckedActionTest.java In more detail: Benchmark 1: com.hp.mwtests.ts.arjuna.atomicaction.CheckedActionTest.testCheckedAction: Start 10 AtomicActions and for each action add a synchronization and 5 child threads and then suspend the action. Then, for each action resume it, remove its child threads and commit it. Benchmark 2: com.hp.mwtests.ts.arjuna.atomicaction.CheckedActionTest.testThreadActionData: Start 2 AtomicActions and manipulate their action hierarchy using currentAction(), restoreActions, popAction and purgeActions {quote} Test 1 (Stack using 1 thread for 300s): 45423 ops/s Test 1 (Stack using 10 threads for 300s): 108201 ops/s Test 2 (Stack using 1 thread for 300s): 651056 ops/s Test 2 (Stack using 10 threads for 300s): 1443719 ops/s Test 1 (Deque using 1 thread for 300s): 47200 ops/s Test 1 (Deque using 10 threads for 300s): 114613 ops/s Test 2 (Deque using 1 thread for 300s): 676561 ops/s Test 2 (Deque using 10 threads for 300s): 1511950 ops/s {quote} Note I cherry picked Jespers Deque implementation on master (5.0.4.Final-SNAPSHOT todays version) and for the Stack implementation I used 5.0.3.Final-SNAPSHOT (the one just before it was tagged). > Use Deque for ThreadActionData > ------------------------------ > > Key: JBTM-2209 > URL: https://issues.jboss.org/browse/JBTM-2209 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Attachments: Test.java > > > Note, there are other usages of java.util.Stack in the code base that could be changed as well -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 07:17:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 07:17:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2250) RecoveryManagerStartStopTest hang waiting for byteman rendezvous In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2250: -------------------------------------- Summary: RecoveryManagerStartStopTest hang waiting for byteman rendezvous Key: JBTM-2250 URL: https://issues.jboss.org/browse/JBTM-2250 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.0.3 Reporter: Michael Musgrove Assignee: Tom Jenkinson Priority: Minor Fix For: 6.0.0 The test hung running CI job narayana-jdbcobjectstore (jstack output attached). Buiid config details are: {quote} Started by upstream project "narayana-jdbcobjectstore" build number 99 originally caused by: Started by user anonymous Building remotely on brandon in workspace /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux Checkout:linux / /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux - hudson.remoting.Channel at 64cff684:brandon Using strategy: Default Last Built Revision: Revision c37dd7bad1eb75837d79f0356baf35d9fae60a81 (origin/master) Wiping out workspace first. Cloning the remote Git repository Cloning repository git://github.com/jbosstm/narayana.git git --version git version 1.7.1 Fetching upstream changes from origin Commencing build of Revision cda46e475c3ce62243cf7c63e68310923cb1930b (origin/master {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 07:18:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 07:18:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2250) RecoveryManagerStartStopTest hang waiting for byteman rendezvous In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2250: ----------------------------------- Attachment: jstack.1125 > RecoveryManagerStartStopTest hang waiting for byteman rendezvous > ---------------------------------------------------------------- > > Key: JBTM-2250 > URL: https://issues.jboss.org/browse/JBTM-2250 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 6.0.0 > > Attachments: jstack.1125 > > > The test hung running CI job narayana-jdbcobjectstore (jstack output attached). Buiid config details are: > {quote} > Started by upstream project "narayana-jdbcobjectstore" build number 99 > originally caused by: > Started by user anonymous > Building remotely on brandon in workspace /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux > Checkout:linux / /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux - hudson.remoting.Channel at 64cff684:brandon > Using strategy: Default > Last Built Revision: Revision c37dd7bad1eb75837d79f0356baf35d9fae60a81 (origin/master) > Wiping out workspace first. > Cloning the remote Git repository > Cloning repository git://github.com/jbosstm/narayana.git > git --version > git version 1.7.1 > Fetching upstream changes from origin > Commencing build of Revision cda46e475c3ce62243cf7c63e68310923cb1930b (origin/master > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 09:49:19 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Sep 2014 09:49:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2209) Use Deque for ThreadActionData In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001875#comment-13001875 ] Tom Jenkinson commented on JBTM-2209: ------------------------------------- Great work on the fix and the benchmark, I agree it looks like it is worth merging. Mike, may I ask you to do the honours please as it is your PR now? > Use Deque for ThreadActionData > ------------------------------ > > Key: JBTM-2209 > URL: https://issues.jboss.org/browse/JBTM-2209 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Attachments: Test.java > > > Note, there are other usages of java.util.Stack in the code base that could be changed as well -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 10:55:24 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 10:55:24 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2209) Use Deque for ThreadActionData In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2209: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/675, https://github.com/jbosstm/narayana/pull/724 (was: https://github.com/jbosstm/narayana/pull/675) > Use Deque for ThreadActionData > ------------------------------ > > Key: JBTM-2209 > URL: https://issues.jboss.org/browse/JBTM-2209 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Attachments: Test.java > > > Note, there are other usages of java.util.Stack in the code base that could be changed as well -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 10:59:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 10:59:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2209) Use Deque for ThreadActionData In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2209. ------------------------------------ Resolution: Done > Use Deque for ThreadActionData > ------------------------------ > > Key: JBTM-2209 > URL: https://issues.jboss.org/browse/JBTM-2209 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Attachments: Test.java > > > Note, there are other usages of java.util.Stack in the code base that could be changed as well -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 10:59:20 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 10:59:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2207) Make default name null in order for quick lookup in BeanPopulator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2207. ------------------------------------ Resolution: Done > Make default name null in order for quick lookup in BeanPopulator > ----------------------------------------------------------------- > > Key: JBTM-2207 > URL: https://issues.jboss.org/browse/JBTM-2207 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:10:20 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 11:10:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2208) Deprecate unused method from ActionManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2208: ----------------------------------- Summary: Deprecate unused method from ActionManager (was: Removed unused method from ActionManager) > Deprecate unused method from ActionManager > ------------------------------------------ > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:11:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 11:11:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2208) Deprecate unused method from ActionManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001924#comment-13001924 ] Michael Musgrove commented on JBTM-2208: ---------------------------------------- I have changed the title of the JIRA from Remove to Deprecate - we will do the actual removal in a couple of releases time. > Deprecate unused method from ActionManager > ------------------------------------------ > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 11:12:19 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Sep 2014 11:12:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2208) Deprecate unused method from ActionManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2208. ------------------------------------ Resolution: Done > Deprecate unused method from ActionManager > ------------------------------------------ > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:34:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Sep 2014 05:34:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2251) Replace killall with pkill in the CI build script In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2251: -------------------------------------- Summary: Replace killall with pkill in the CI build script Key: JBTM-2251 URL: https://issues.jboss.org/browse/JBTM-2251 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.0.3 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 4.17.23, 5.0.3 Some of our CI machines are missing killall which is non-standard. Replace it with pkill. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:55:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 15 Sep 2014 05:55:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2252) QA suite failure: CrashRecovery05_2_Test030 In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2252: ------------------------------------- Summary: QA suite failure: CrashRecovery05_2_Test030 Key: JBTM-2252 URL: https://issues.jboss.org/browse/JBTM-2252 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS, Testing Reporter: Gytis Trikleris Assignee: Michael Musgrove Priority: Minor Fix For: 5.0.4 http://172.17.131.2/view/Status/job/narayana/638/PROFILE=QA_JTS_JACORB,jdk=jdk7.latest,label=linux -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 05:59:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 15 Sep 2014 05:59:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2253) UnknownHost brandon.buildnet.ncl.jboss.com In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2253: ------------------------------------- Summary: UnknownHost brandon.buildnet.ncl.jboss.com Key: JBTM-2253 URL: https://issues.jboss.org/browse/JBTM-2253 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie, Testing Reporter: Gytis Trikleris Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.0.4 http://172.17.131.2/view/Status/job/narayana/639/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ {code} 12:39:56,830 ERROR [org.codehaus.stomp.jms.ProtocolConverter] (StompConnect Transport: tcp:///127.0.0.1:44813) Connection is closed: org.codehaus.stomp.jms.ProtocolConverter at 10c10e8 12:39:56,831 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///127.0.0.1:44813) Caught an exception: Broken pipe: java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) [rt.jar:1.7.0_51] at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) [rt.jar:1.7.0_51] at java.net.SocketOutputStream.write(SocketOutputStream.java:159) [rt.jar:1.7.0_51] at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_51] at java.io.FilterOutputStream.write(FilterOutputStream.java:97) [rt.jar:1.7.0_51] at org.codehaus.stomp.StompMarshaller.marshal(StompMarshaller.java:83) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] at org.codehaus.stomp.tcp.TcpTransport.onStompFrame(TcpTransport.java:80) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] at org.codehaus.stomp.jms.ProtocolConverter.sendToStomp(ProtocolConverter.java:498) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:209) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:101) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 110.88 sec Running org.jboss.narayana.blacktie.jatmibroker.xatmi.TestTopic Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.162 sec Running org.jboss.narayana.blacktie.jatmibroker.xatmi.server.BlackTieServerTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.248 sec Results : Tests in error: AtmiBrokerEnvXMLTest.testEnv:53 ? UnknownHost brandon.buildnet.ncl.jboss.com: ... TestConnection.setUp:29 ? Configuration Could not create the orb management fu... {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:00:11 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 15 Sep 2014 06:00:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2253) Brandon CI node misconfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2253: ---------------------------------- Summary: Brandon CI node misconfiguration (was: UnknownHost brandon.buildnet.ncl.jboss.com) > Brandon CI node misconfiguration > --------------------------------- > > Key: JBTM-2253 > URL: https://issues.jboss.org/browse/JBTM-2253 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/639/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ > {code} > 12:39:56,830 ERROR [org.codehaus.stomp.jms.ProtocolConverter] (StompConnect Transport: tcp:///127.0.0.1:44813) Connection is closed: org.codehaus.stomp.jms.ProtocolConverter at 10c10e8 > 12:39:56,831 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///127.0.0.1:44813) Caught an exception: Broken pipe: java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.write(SocketOutputStream.java:159) [rt.jar:1.7.0_51] > at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_51] > at java.io.FilterOutputStream.write(FilterOutputStream.java:97) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.marshal(StompMarshaller.java:83) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.onStompFrame(TcpTransport.java:80) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.sendToStomp(ProtocolConverter.java:498) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:209) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:101) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 110.88 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.TestTopic > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.162 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.server.BlackTieServerTestCase > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.248 sec > Results : > Tests in error: > AtmiBrokerEnvXMLTest.testEnv:53 ? UnknownHost brandon.buildnet.ncl.jboss.com: ... > TestConnection.setUp:29 ? Configuration Could not create the orb management fu... > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:09:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 15 Sep 2014 06:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2254) NPE during commit in TestATSubordinateCrashDuringCommit.subordinateMultiParticipantPrepareAndCommitTest In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2254: ------------------------------------- Summary: NPE during commit in TestATSubordinateCrashDuringCommit.subordinateMultiParticipantPrepareAndCommitTest Key: JBTM-2254 URL: https://issues.jboss.org/browse/JBTM-2254 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Reporter: Gytis Trikleris Assignee: Paul Robinson Priority: Minor Fix For: 5.0.4 http://172.17.131.2/view/Status/job/narayana/644/PROFILE=XTS,jdk=jdk7.latest,label=linux {code} ------------------------------------------------------------------------------- Test set: com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 693.702 sec <<< FAILURE! subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit) Time elapsed: 693.694 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.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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.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.client.container.ClientContainerController.kill(ClientContainerController.java:230) at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:216) at com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringCommit.java:17) {code} {code} 20:55:12,560 WARN [com.arjuna.ws.wscf] (TaskWorker-1) ARJUNA044053: ParticipantRecord.topLevelCommit 0:ffffac118321:-4fba645d:54134f08:33 caught exception: java.lang.NullPointerException at com.arjuna.wst11.messaging.engines.CoordinatorEngine.sendCommit(CoordinatorEngine.java:654) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.wst11.messaging.engines.CoordinatorEngine.commit(CoordinatorEngine.java:326) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.wst11.stub.ParticipantStub.commit(ParticipantStub.java:96) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.mwlabs.wst.at.participants.DurableTwoPhaseCommitParticipant.confirm(DurableTwoPhaseCommitParticipant.java:145) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.ParticipantRecord.topLevelCommit(ParticipantRecord.java:261) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2851) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2767) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1854) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.commit(SubordinateATCoordinator.java:183) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.wst11.stub.SubordinateDurable2PCStub.commit(SubordinateDurable2PCStub.java:104) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.wst11.messaging.engines.ParticipantEngine.executeCommit(ParticipantEngine.java:576) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.wst11.messaging.engines.ParticipantEngine.commit(ParticipantEngine.java:149) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.wst11.messaging.ParticipantProcessorImpl.commit(ParticipantProcessorImpl.java:99) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.webservices11.wsat.sei.ParticipantPortTypeImpl$2.executeTask(ParticipantPortTypeImpl.java:84) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:63) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:10:03 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 15 Sep 2014 06:10:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2254) NPE during commit in TestATSubordinateCrashDuringCommit.subordinateMultiParticipantPrepareAndCommitTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reassigned JBTM-2254: ------------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > NPE during commit in TestATSubordinateCrashDuringCommit.subordinateMultiParticipantPrepareAndCommitTest > ------------------------------------------------------------------------------------------------------- > > Key: JBTM-2254 > URL: https://issues.jboss.org/browse/JBTM-2254 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/644/PROFILE=XTS,jdk=jdk7.latest,label=linux > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 693.702 sec <<< FAILURE! > subordinateMultiParticipantPrepareAndCommitTest(com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit) Time elapsed: 693.694 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.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > 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.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > 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.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.client.container.ClientContainerController.kill(ClientContainerController.java:230) > at com.arjuna.qa.junit.BaseCrashTest.runTest(BaseCrashTest.java:216) > at com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit.subordinateMultiParticipantPrepareAndCommitTest(TestATSubordinateCrashDuringCommit.java:17) > {code} > {code} > 20:55:12,560 WARN [com.arjuna.ws.wscf] (TaskWorker-1) ARJUNA044053: ParticipantRecord.topLevelCommit 0:ffffac118321:-4fba645d:54134f08:33 caught exception: java.lang.NullPointerException > at com.arjuna.wst11.messaging.engines.CoordinatorEngine.sendCommit(CoordinatorEngine.java:654) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.wst11.messaging.engines.CoordinatorEngine.commit(CoordinatorEngine.java:326) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.wst11.stub.ParticipantStub.commit(ParticipantStub.java:96) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.mwlabs.wst.at.participants.DurableTwoPhaseCommitParticipant.confirm(DurableTwoPhaseCommitParticipant.java:145) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.ParticipantRecord.topLevelCommit(ParticipantRecord.java:261) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2851) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2767) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1854) [narayana-jts-jacorb-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.commit(SubordinateATCoordinator.java:183) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.wst11.stub.SubordinateDurable2PCStub.commit(SubordinateDurable2PCStub.java:104) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.wst11.messaging.engines.ParticipantEngine.executeCommit(ParticipantEngine.java:576) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.wst11.messaging.engines.ParticipantEngine.commit(ParticipantEngine.java:149) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.wst11.messaging.ParticipantProcessorImpl.commit(ParticipantProcessorImpl.java:99) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.webservices11.wsat.sei.ParticipantPortTypeImpl$2.executeTask(ParticipantPortTypeImpl.java:84) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:63) [jbossxts-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT (revision: a3ef7)] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:18:03 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Sep 2014 06:18:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2253) Brandon CI node misconfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2253. ------------------------------------ Resolution: Done Tom pushed a commit for this last week: 6b238a00a63d73cfe904a167f42116327a647c2a > Brandon CI node misconfiguration > --------------------------------- > > Key: JBTM-2253 > URL: https://issues.jboss.org/browse/JBTM-2253 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/639/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ > {code} > 12:39:56,830 ERROR [org.codehaus.stomp.jms.ProtocolConverter] (StompConnect Transport: tcp:///127.0.0.1:44813) Connection is closed: org.codehaus.stomp.jms.ProtocolConverter at 10c10e8 > 12:39:56,831 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///127.0.0.1:44813) Caught an exception: Broken pipe: java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.write(SocketOutputStream.java:159) [rt.jar:1.7.0_51] > at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_51] > at java.io.FilterOutputStream.write(FilterOutputStream.java:97) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.marshal(StompMarshaller.java:83) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.onStompFrame(TcpTransport.java:80) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.sendToStomp(ProtocolConverter.java:498) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:209) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:101) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 110.88 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.TestTopic > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.162 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.server.BlackTieServerTestCase > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.248 sec > Results : > Tests in error: > AtmiBrokerEnvXMLTest.testEnv:53 ? UnknownHost brandon.buildnet.ncl.jboss.com: ... > TestConnection.setUp:29 ? Configuration Could not create the orb management fu... > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:21:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Sep 2014 06:21:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2251) Replace killall with pkill in the CI build script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2251: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/725 > Replace killall with pkill in the CI build script > ------------------------------------------------- > > Key: JBTM-2251 > URL: https://issues.jboss.org/browse/JBTM-2251 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > Some of our CI machines are missing killall which is non-standard. Replace it with pkill. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:22:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Sep 2014 06:22:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2251) Replace killall with pkill in the CI build script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2251: ----------------------------------- Fix Version/s: (was: 4.17.23) > Replace killall with pkill in the CI build script > ------------------------------------------------- > > Key: JBTM-2251 > URL: https://issues.jboss.org/browse/JBTM-2251 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.3 > > > Some of our CI machines are missing killall which is non-standard. Replace it with pkill. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:23:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Sep 2014 06:23:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2251) Replace killall with pkill in the CI build script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002275#comment-13002275 ] Michael Musgrove commented on JBTM-2251: ---------------------------------------- I have removed the fix version for the 4.17 branch (killall only affects BlackTie which we don't test on the 4.17 branch) > Replace killall with pkill in the CI build script > ------------------------------------------------- > > Key: JBTM-2251 > URL: https://issues.jboss.org/browse/JBTM-2251 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.3 > > > Some of our CI machines are missing killall which is non-standard. Replace it with pkill. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:46:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:46:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2251) Replace killall with pkill in the CI build script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2251: -------------------------------- Fix Version/s: 5.0.4 (was: 5.0.3) > Replace killall with pkill in the CI build script > ------------------------------------------------- > > Key: JBTM-2251 > URL: https://issues.jboss.org/browse/JBTM-2251 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > Some of our CI machines are missing killall which is non-standard. Replace it with pkill. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:49:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:49:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2136) XATMI CSTest does not complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2136: -------------------------------- Fix Version/s: (was: 5.0.2) > XATMI CSTest does not complete > ------------------------------ > > Key: JBTM-2136 > URL: https://issues.jboss.org/browse/JBTM-2136 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-windows2008-taconic/568 > {code} > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.CSTest > 19:46:48,877 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 92) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 > 19:46:48,878 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 92) JBAS011601: Bound messaging object to jndi name /queue/BTR_.testsui1 > 19:46:51,301 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 92) HQ221003: trying to deploy queue jms.queue.BTR_BAR > 19:46:51,301 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 92) JBAS011601: Bound messaging object to jndi name /queue/BTR_BAR > 19:46:51,442 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 92) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall > 19:46:51,450 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 92) JBAS011601: Bound messaging object to jndi name /queue/BTR_TestTPCall > 19:46:54,895 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62781) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:46:54,896 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62784) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:46:54,897 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62786) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:03,166 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62794) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:03,172 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62796) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:03,581 WARN [org.jboss.narayana.blacktie.administration.QueueReaperBean] (EJB default - 7) undeploy service pending for .testsui1 as consumer count is 0, will check again in 30000ms > 19:47:13,984 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62801) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:13,985 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62804) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:13,986 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62806) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:23,619 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62813) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:23,620 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62816) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:23,621 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62818) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:33,418 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62825) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:33,419 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62828) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:33,419 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///172.17.131.21:62830) Caught an exception: Connection reset: java.net.SocketException: Connection reset > at java.net.SocketInputStream.read(SocketInputStream.java:196) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] > at java.net.SocketInputStream.read(SocketInputStream.java:210) [rt.jar:1.7.0_51] > at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.readLine(StompMarshaller.java:183) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.StompMarshaller.unmarshal(StompMarshaller.java:94) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:98) [wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:47:36,234 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 93) JBAS011605: Unbound messaging object to jndi name java:/queue/BTR_.testsui1 > 19:47:36,435 WARN [org.jboss.narayana.blacktie.administration.QueueReaperBean] (EJB default - 7) undeploy service .testsui1 for consumer is 0 > 19:47:37,469 ERROR [org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService] (Thread-43 (HornetQ-client-global-threads-18526631)) Could not deploy queue of .testsui1: javax.management.InstanceNotFoundException: jboss.as:subsystem=messaging,hornetq-server=default,jms-queue=BTR_.testsui1 > at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1085) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:380) > at org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService.consumerCount(BlacktieStompAdministrationService.java:197) [blacktie-admin-services-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService.deployQueue(BlacktieStompAdministrationService.java:305) [blacktie-admin-services-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService.tpservice(BlacktieStompAdministrationService.java:415) [blacktie-admin-services-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.jboss.narayana.blacktie.jatmibroker.xatmi.BlackTieService.processMessage(BlackTieService.java:182) [blacktie-jatmibroker-xatmi-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.jboss.narayana.blacktie.jatmibroker.xatmi.mdb.MDBBlacktieService.onMessage(MDBBlacktieService.java:66) [blacktie-jatmibroker-xatmi-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) [:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:260) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.never(CMTTxInterceptor.java:310) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:235) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:211) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:448) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:182) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService$$$view2.onMessage(Unknown Source) [blacktie-admin-services-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) [:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) [wildfly-ejb3-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService$$$endpoint3.onMessage(Unknown Source) [blacktie-admin-services-5.0.2.Final-SNAPSHOT.jar:5.0.2.Final-SNAPSHOT] > at org.hornetq.ra.inflow.HornetQMessageHandler.onMessage(HornetQMessageHandler.java:319) > at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1116) > at org.hornetq.core.client.impl.ClientConsumerImpl.access$500(ClientConsumerImpl.java:56) > at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1251) > at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:104) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:48:10,345 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 19:48:10,359 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 19:48:10,364 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 19:48:10,368 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 19:50:20,375 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 19:50:20,388 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 19:50:20,392 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 19:50:20,396 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 19:52:30,405 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 19:52:30,418 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 19:52:30,422 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 19:52:30,426 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 19:54:40,500 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 19:54:40,512 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 19:54:40,516 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 19:54:40,520 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 19:56:50,532 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 19:56:50,541 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 19:56:50,545 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 19:56:50,549 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 19:59:00,559 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 19:59:00,573 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 19:59:00,578 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 19:59:00,582 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 20:01:10,589 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 20:01:10,604 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 20:01:10,608 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 20:01:10,612 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 20:03:20,621 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 20:03:20,625 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 20:03:20,629 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 20:03:20,633 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 20:05:30,642 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 20:05:30,653 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 20:05:30,656 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 20:05:30,660 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 20:07:40,669 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > 20:07:40,678 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a8%3a129882/terminate > 20:07:40,682 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a11%3a632812/terminate > 20:07:40,686 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a11%3a931640/terminate > 20:09:50,696 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a7%3a884765/terminate > ... > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:49:05 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:49:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2135) QA suite failure: CrashRecovery08_Test22 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2135: -------------------------------- Fix Version/s: (was: 5.0.2) > QA suite failure: CrashRecovery08_Test22 > ---------------------------------------- > > Key: JBTM-2135 > URL: https://issues.jboss.org/browse/JBTM-2135 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Attachments: narayana-jdbcobjectstore_67_mysql_CrashRecovery08_Test22.zip > > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/67/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/consoleText -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:49:06 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:49:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2109) Blacktie test does not complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2109: -------------------------------- Fix Version/s: (was: 5.0.2) > Blacktie test does not complete > ------------------------------- > > Key: JBTM-2109 > URL: https://issues.jboss.org/browse/JBTM-2109 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/452/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:49:07 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:49:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2100) PauseDomainTest failed: connection reset In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2100: -------------------------------- Fix Version/s: (was: 5.0.2) > PauseDomainTest failed: connection reset > ---------------------------------------- > > Key: JBTM-2100 > URL: https://issues.jboss.org/browse/JBTM-2100 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/427/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:49:07 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:49:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2145) Blacktie subsystem configuration build fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2145: -------------------------------- Fix Version/s: (was: 5.0.2) > Blacktie subsystem configuration build fails > -------------------------------------------- > > Key: JBTM-2145 > URL: https://issues.jboss.org/browse/JBTM-2145 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Blocker > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-codeCoverage/113 > {code} > [INFO] ------------------------------------------------------------------------ > [INFO] Building WildFly: Blacktie Subsystem Build 5.0.2.Final-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.2:create-timestamp (get-build-timestamp) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- jacoco-maven-plugin:0.6.3.201306030806:prepare-agent (pre-unit-test) @ wildfly-blacktie-build --- > [INFO] Skipping JaCoCo for project with packaging type 'pom' > [INFO] surefireArgLine set to > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (build-blacktie-modular-config) @ wildfly-blacktie-build --- > [INFO] Executing tasks > main: > modules-minimalistic: > [echo] Initializing module -> org.wildfly.extension.blacktie > [mkdir] Created dir: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/blacktie/main > [copy] Copying 1 file to /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/blacktie/main > [copy] Copying 1 file to /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/blacktie/main > [INFO] Executed tasks > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (generate-blacktie-config) @ wildfly-blacktie-build --- > [INFO] Executing tasks > main: > generate-configs: > [mkdir] Created dir: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT/docs/examples/configs > [echo] Merging standalone configuration/standalone/template.xml and /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/src/main/resources/configuration/examples/subsystems-blacktie.xml into /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT/docs/examples/configs/standalone-blacktie.xml, using StandaloneMain > [java] java.lang.IllegalStateException: Could not find '[subsystem=../../../../../../jboss-as/build/src/main/resources/configuration/subsystems/threads.xml, supplement=null]' under the base directory '/home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/src/main/resources' > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194) > [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771) > [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221) > [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135) > [java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.Target.execute(Target.java:390) > [java] at org.apache.tools.ant.Target.performTasks(Target.java:411) > [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > [java] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) > [java] at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > [java] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.Target.execute(Target.java:390) > [java] at org.apache.tools.ant.Target.performTasks(Target.java:411) > [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > [java] at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > [java] at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327) > [java] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > [java] at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > [java] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > [java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > [java] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > [java] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > [java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > [java] Caused by: java.lang.IllegalStateException: Could not find '[subsystem=../../../../../../jboss-as/build/src/main/resources/configuration/subsystems/threads.xml, supplement=null]' under the base directory '/home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/src/main/resources' > [java] at org.jboss.as.config.assembly.ConfigurationAssembler.populateTemplate(ConfigurationAssembler.java:109) > [java] at org.jboss.as.config.assembly.ConfigurationAssembler.assemble(ConfigurationAssembler.java:64) > [java] at org.jboss.as.config.assembly.StandaloneMain.main(StandaloneMain.java:53) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:601) > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217) > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152) > [java] ... 76 more > [java] Java Result: -1 > all: > [INFO] Executed tasks > [INFO] > [INFO] --- byteman-rulecheck-maven-plugin:2.1.3:rulecheck (rulecheck) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- jacoco-maven-plugin:0.6.3.201306030806:report (post-unit-test) @ wildfly-blacktie-build --- > [INFO] Skipping JaCoCo for project with packaging type 'pom' > [INFO] > [INFO] --- jacoco-maven-plugin:0.6.3.201306030806:check (check) @ wildfly-blacktie-build --- > [INFO] Skipping JaCoCo for project with packaging type 'pom' > [INFO] > [INFO] >>> maven-source-plugin:2.2.1:jar (attach-sources) @ wildfly-blacktie-build >>> > [INFO] > [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.2:create-timestamp (get-build-timestamp) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- jacoco-maven-plugin:0.6.3.201306030806:prepare-agent (pre-unit-test) @ wildfly-blacktie-build --- > [INFO] Skipping JaCoCo for project with packaging type 'pom' > [INFO] surefireArgLine set to > [INFO] > [INFO] <<< maven-source-plugin:2.2.1:jar (attach-sources) @ wildfly-blacktie-build <<< > [INFO] > [INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- maven-source-plugin:2.2.1:jar-no-fork (attach-sources) @ wildfly-blacktie-build --- > [INFO] > [INFO] --- maven-assembly-plugin:2.4:single (make-assembly) @ wildfly-blacktie-build --- > [INFO] Reading assembly descriptor: src/main/assembly/zip.xml > [INFO] Building zip: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT-bin.zip > [INFO] > [INFO] --- maven-install-plugin:2.4:install (default-install) @ wildfly-blacktie-build --- > [INFO] Installing /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/pom.xml to /home/hudson/.m2/repository/org/jboss/narayana/blacktie/wildfly-blacktie-build/5.0.2.Final-SNAPSHOT/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT.pom > [INFO] Installing /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT-bin.zip to /home/hudson/.m2/repository/org/jboss/narayana/blacktie/wildfly-blacktie-build/5.0.2.Final-SNAPSHOT/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT-bin.zip > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] WildFly: Blacktie Subsystem Parent ................ SUCCESS [2.417s] > [INFO] WildFly: Blacktie Subsystem ....................... SUCCESS [8.332s] > [INFO] WildFly: Blacktie Subsystem Build ................. SUCCESS [1.941s] > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 13.141s > [INFO] Finished at: Fri Apr 04 23:23:50 BST 2014 > [INFO] Final Memory: 56M/253M > [INFO] ------------------------------------------------------------------------ > Archive: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-blacktie/build/target/wildfly-blacktie-build-5.0.2.Final-SNAPSHOT-bin.zip > creating: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/blacktie/ > creating: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/blacktie/main/ > extracting: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/blacktie/main/wildfly-blacktie-5.0.2.Final-SNAPSHOT.jar > inflating: /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/blacktie/main/module.xml > Buildfile: /home/hudson/workspace/narayana-codeCoverage/blacktie/scripts/hudson/initializeJBoss.xml > initializeJBoss: > BUILD FAILED > /home/hudson/workspace/narayana-codeCoverage/blacktie/scripts/hudson/initializeJBoss.xml:5: Warning: Could not find file /home/hudson/workspace/narayana-codeCoverage/blacktie/wildfly-8.0.1.Final-SNAPSHOT/docs/examples/configs/standalone-blacktie.xml to copy. > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:51:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:51:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2192) Use org.jboss.logging.annotations instead of the old deprecated package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2192: -------------------------------- Fix Version/s: (was: 5.0.3) > Use org.jboss.logging.annotations instead of the old deprecated package > ----------------------------------------------------------------------- > > Key: JBTM-2192 > URL: https://issues.jboss.org/browse/JBTM-2192 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:51:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:51:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2200) standalone-blacktie.xml is not available In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2200: -------------------------------- Fix Version/s: (was: 5.0.3) > standalone-blacktie.xml is not available > ---------------------------------------- > > Key: JBTM-2200 > URL: https://issues.jboss.org/browse/JBTM-2200 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > > http://172.17.131.2/view/Status/job/narayana-windows2008-taconic/644 > {code} > generate-configs: > [mkdir] Created dir: C:\hudson\workspace\narayana-windows2008-taconic\blacktie\wildfly-blacktie\build\target\wildfly-blacktie-build-5.0.3.Final-SNAPSHOT\docs\examples\configs > [echo] Merging standalone configuration/standalone/template.xml and C:\hudson\workspace\narayana-windows2008-taconic\blacktie\wildfly-blacktie\build/src/main/resources/configuration/examples/subsystems-blacktie.xml into C:\hudson\workspace\narayana-windows2008-taconic\blacktie\wildfly-blacktie\build/target/wildfly-blacktie-build-5.0.3.Final-SNAPSHOT/docs/examples/configs/standalone-blacktie.xml, using StandaloneMain > [java] java.lang.IllegalStateException: Could not find '[subsystem=../../../../../../jboss-as/build/src/main/resources/configuration/subsystems/logging.xml, supplement=null]' under the base directory 'C:\hudson\workspace\narayana-windows2008-taconic\blacktie\wildfly-blacktie\build\src\main\resources' > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194) > [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771) > [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221) > [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135) > [java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.Target.execute(Target.java:390) > [java] at org.apache.tools.ant.Target.performTasks(Target.java:411) > [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > [java] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) > [java] at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > [java] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > [java] at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > [java] at org.apache.tools.ant.Task.perform(Task.java:348) > [java] at org.apache.tools.ant.Target.execute(Target.java:390) > [java] at org.apache.tools.ant.Target.performTasks(Target.java:411) > [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > [java] at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > [java] at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327) > [java] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > [java] at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > [java] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > [java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > [java] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > [java] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > [java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > [java] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > [java] Caused by: java.lang.IllegalStateException: Could not find '[subsystem=../../../../../../jboss-as/build/src/main/resources/configuration/subsystems/logging.xml, supplement=null]' under the base directory 'C:\hudson\workspace\narayana-windows2008-taconic\blacktie\wildfly-blacktie\build\src\main\resources' > [java] at org.jboss.as.config.assembly.ConfigurationAssembler.populateTemplate(ConfigurationAssembler.java:109) > [java] at org.jboss.as.config.assembly.ConfigurationAssembler.assemble(ConfigurationAssembler.java:64) > [java] at org.jboss.as.config.assembly.StandaloneMain.main(StandaloneMain.java:53) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [java] at java.lang.reflect.Method.invoke(Method.java:606) > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217) > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152) > [java] ... 76 more > [java] Java Result: -1 > {code} > {code} > BUILD FAILED > C:\hudson\workspace\narayana-windows2008-taconic\blacktie\scripts\hudson\initializeJBoss.xml:5: Warning: Could not find file C:\hudson\workspace\narayana-windows2008-taconic\blacktie\wildfly-9.0.0.Alpha1-SNAPSHOT\docs\examples\configs\standalone-blacktie.xml to copy. > at org.apache.tools.ant.taskdefs.Copy.copySingleFile(Copy.java:619) > at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:444) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:390) > at org.apache.tools.ant.Target.performTasks(Target.java:411) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > at org.apache.tools.ant.Main.runBuild(Main.java:809) > at org.apache.tools.ant.Main.startAnt(Main.java:217) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:51:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:51:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2235) QA test quite failure: RawResources01_2_Test037 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2235: -------------------------------- Fix Version/s: (was: 5.0.3) > QA test quite failure: RawResources01_2_Test037 > ----------------------------------------------- > > Key: JBTM-2235 > URL: https://issues.jboss.org/browse/JBTM-2235 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Attachments: RawResources01_2_Test037.tar > > > http://172.17.131.2/view/Status/job/narayana/605/PROFILE=QA_JTS_JDKORB,jdk=jdk7.latest,label=linux/ -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:51:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:51:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2230) XAResourceWrapper needs an RM id property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2230: -------------------------------- Fix Version/s: (was: 5.0.3) > XAResourceWrapper needs an RM id property > ----------------------------------------- > > Key: JBTM-2230 > URL: https://issues.jboss.org/browse/JBTM-2230 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: SPI > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > With JMS there are some configurations where the jndi name is not guaranteed to be unique so when diagnosing recovery issues just reporting this jndi name is insufficient for identifying which server created the XID that is being recovered. > We can resolve this issue by providing a unique id that identifies the resource manager that created the XID. The proposal is to add this id to the transactions SPI (specifically to the org.jboss.tm.XAResourceWrapper interface) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:54:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:54:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1992) (IDLJ) QA test suite failure: CrashRecovery08_Test17 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1992: -------------------------------- Fix Version/s: (was: 6.0.0) > (IDLJ) QA test suite failure: CrashRecovery08_Test17 > ---------------------------------------------------- > > Key: JBTM-1992 > URL: https://issues.jboss.org/browse/JBTM-1992 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Attachments: testoutput-idlj.zip > > > Test Failures: > crashrecovery08 CrashRecovery08_Test17 Fail -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:54:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:54:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1981) Provide a quickstart that shows how to enlist a JDBC resource outside of the application server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1981: -------------------------------- Fix Version/s: (was: 6.0.0) > Provide a quickstart that shows how to enlist a JDBC resource outside of the application server > ----------------------------------------------------------------------------------------------- > > Key: JBTM-1981 > URL: https://issues.jboss.org/browse/JBTM-1981 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Minor > > It would be useful to see how to use a JDBC connection outside of the application server. The example should demonstrate recovery. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:54:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:54:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1932) Consider using the same jboss-parent as other JBoss community projects such as WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1932: -------------------------------- Fix Version/s: (was: 6.0.0) > Consider using the same jboss-parent as other JBoss community projects such as WildFly > -------------------------------------------------------------------------------------- > > Key: JBTM-1932 > URL: https://issues.jboss.org/browse/JBTM-1932 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Minor > > It would standardise the versions of the build plugins we use and would ensure that we build with java versions that are compatible with WildFly. On the flip side it will restrict our community options although many of the variables do appear to be configurable: > https://github.com/jboss/jboss-parent-pom/ -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:54:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:54:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1986) There are some redundant QA crash recovery tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1986: -------------------------------- Fix Version/s: (was: 6.0.0) > There are some redundant QA crash recovery tests > ------------------------------------------------ > > Key: JBTM-1986 > URL: https://issues.jboss.org/browse/JBTM-1986 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.0.M6 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > > I notice that there are some test duplicates in the org.jboss.jbossts.qa.CrashRecovery05Clients1.CrashRecovery05Clients1 group. I did not check any of the other groups so the assignee should also check those too. It is also worth checking whether the duplicates can be tweaked to test a scenario not covered by any of the other tests in the group. > The duplicates are: > - CrashRecovery05Clients1.Client01a and CrashRecovery05Clients1.Client02a > - CrashRecovery05Clients1.Client03a, CrashRecovery05Clients1.Client04a and CrashRecovery05Clients1.Client05a -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:54:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:54:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2162) Change CMR commit failure message In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2162. ------------------------------- > Change CMR commit failure message > --------------------------------- > > Key: JBTM-2162 > URL: https://issues.jboss.org/browse/JBTM-2162 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.17.19 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Trivial > Fix For: 4.17.20 > > > If a transaction containing an XA and a CMR resource is committed and the CMR resource fails the commit then the warning message mentions onePhaseCommit. Even though the CMR is in reality a one phase resource the message can be confusing. > Please change the message to something more generic. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:55:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:55:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2140) Services do not enlist RMs if the client begins a transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2140. ------------------------------- > Services do not enlist RMs if the client begins a transaction > -------------------------------------------------------------- > > Key: JBTM-2140 > URL: https://issues.jboss.org/browse/JBTM-2140 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.1 > > > If a client starts a transaction and makes a service call then service does not enlist the RMs into the transaction. > When the service creates an HttpControl instance for the incoming transaction it needs to repopulate the _enlistUrl and _endUrl by calling HttpControl::headRequest(). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:57:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:57:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2208) Deprecate unused method from ActionManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2208: -------------------------------- Fix Version/s: 5.0.4 > Deprecate unused method from ActionManager > ------------------------------------------ > > Key: JBTM-2208 > URL: https://issues.jboss.org/browse/JBTM-2208 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > Removed unused method from ActionManager, and thereby a System.currentTimeMillis call -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:57:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:57:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2207) Make default name null in order for quick lookup in BeanPopulator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2207: -------------------------------- Fix Version/s: 5.0.4 > Make default name null in order for quick lookup in BeanPopulator > ----------------------------------------------------------------- > > Key: JBTM-2207 > URL: https://issues.jboss.org/browse/JBTM-2207 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:57:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:57:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2209) Use Deque for ThreadActionData In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2209: -------------------------------- Fix Version/s: 5.0.4 > Use Deque for ThreadActionData > ------------------------------ > > Key: JBTM-2209 > URL: https://issues.jboss.org/browse/JBTM-2209 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Fix For: 5.0.4 > > Attachments: Test.java > > > Note, there are other usages of java.util.Stack in the code base that could be changed as well -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:58:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:58:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2248) Sansa doesn't have Ant installed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2248: -------------------------------- Fix Version/s: 5.0.4 > Sansa doesn't have Ant installed > -------------------------------- > > Key: JBTM-2248 > URL: https://issues.jboss.org/browse/JBTM-2248 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.4 > > > Jenkins node Sansa does not have Ant installed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:58:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:58:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2236) Remove / from ConfigurationInfo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2236: -------------------------------- Fix Version/s: 5.0.3 > Remove / from ConfigurationInfo > ------------------------------- > > Key: JBTM-2236 > URL: https://issues.jboss.org/browse/JBTM-2236 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Common > Affects Versions: 5.0.2 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.0.3 > > > I've been working on compiling Java using the Avian project (http://oss.readytalk.com/avian/) and have eventually had success in running some of our hammer tests. However, there was a blocker which was to do with the way in which we locate the property file within the jar using the manifest. We can argue as to whether the issue resides within Avian or the way in which we do things, but the solution was to simply remove the / from: > int suffixLength = ("/"+ConfigurationInfo.class.getCanonicalName()+".class").length(); > Rebuilding and rerunning the tests made everything work. > I don't want to check in this change until I am sure that it is right, so would appreciate someone looking at it and at least running all of the QE tests to be sure nothing else breaks. > I've included a reference to the Avian forum article where I discussed this with their team. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:58:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:58:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2231) Detailed TRACE logging for Synchronization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2231: -------------------------------- Fix Version/s: 5.0.3 > Detailed TRACE logging for Synchronization > ------------------------------------------ > > Key: JBTM-2231 > URL: https://issues.jboss.org/browse/JBTM-2231 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Fix For: 5.0.3 > > > Provide TRACE logging of Synchronization interactions. > * Adding Synchronization through registerSynchronization > * Adding Synchronization through registerInterposedSynchronization > * Call of beforeCompletion > * Call of afterCompletion > Each TRACE statement needs > * Class name > * Identity hash code > * toString -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:59:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:59:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2199) CI Build: narayana-AS800 out of heap space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2199. ------------------------------- > CI Build: narayana-AS800 out of heap space > ------------------------------------------ > > Key: JBTM-2199 > URL: https://issues.jboss.org/browse/JBTM-2199 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Environment: janei > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > > http://172.17.131.2/view/Status/job/narayana-AS800/542 > {code} > [INFO] Reactor Summary: > [INFO] > [INFO] WildFly: Build Configuration ...................... SUCCESS [ 4.227 s] > [INFO] WildFly: Parent Aggregator ........................ SUCCESS [ 2.822 s] > [INFO] WildFly: Protocol Utilities ....................... SUCCESS [ 20.544 s] > [INFO] WildFly: Controller Client ........................ SUCCESS [ 10.512 s] > [INFO] WildFly: Core Security parent ..................... SUCCESS [ 0.111 s] > [INFO] WildFly: Core Security API ........................ SUCCESS [ 0.860 s] > [INFO] WildFly: Core Security Utilities .................. SUCCESS [ 1.535 s] > [INFO] WildFly: Controller Core .......................... SUCCESS [ 30.416 s] > [INFO] WildFly: Deployment Repository .................... SUCCESS [ 6.177 s] > [INFO] WildFly: Version .................................. SUCCESS [ 1.264 s] > [INFO] WildFly: Process Controller ....................... SUCCESS [ 4.984 s] > [INFO] WildFly: Command line interface ................... SUCCESS [ 10.838 s] > [INFO] WildFly: Patching Core ............................ SUCCESS [ 4.899 s] > [INFO] WildFly: Platform MBean integration ............... SUCCESS [ 1.987 s] > [INFO] WildFly: Domain Management ........................ SUCCESS [ 13.985 s] > [INFO] WildFly: Domain HTTP Interface .................... SUCCESS [ 0.066 s] > [INFO] WildFly: Domain HTTP Interface .................... SUCCESS [ 1.497 s] > [INFO] WildFly: IO aggregator ............................ SUCCESS [ 0.079 s] > [INFO] WildFly: IO Subsystem ............................. SUCCESS [ 0.862 s] > [INFO] WildFly: Network .................................. SUCCESS [ 0.671 s] > [INFO] WildFly: Remoting Subsystem parent ................ SUCCESS [ 0.059 s] > [INFO] WildFly: Remoting Subsystem ....................... SUCCESS [ 3.072 s] > [INFO] WildFly: Server ................................... SUCCESS [ 9.235 s] > [INFO] WildFly: Management Client Content ................ SUCCESS [ 0.771 s] > [INFO] WildFly: Common Code for Subsystem and Non-subsystem Test Harness SUCCESS [ 1.612 s] > [INFO] WildFly: Host Controller .......................... SUCCESS [ 11.954 s] > [INFO] WildFly: Core Model Test Parent ................... SUCCESS [ 0.518 s] > [INFO] WildFly: Core Model Test Framework ................ SUCCESS [ 1.287 s] > [INFO] WildFly: Embedded ................................. SUCCESS [ 1.218 s] > [INFO] WildFly: Domain HTTP Error Context ................ SUCCESS [ 0.380 s] > [INFO] WildFly: Core Model Test Parent ................... SUCCESS [ 0.089 s] > [INFO] WildFly: Subsystem Test Harness ................... SUCCESS [ 3.020 s] > [INFO] WildFly: Subsystem Test Controller 7.2.0 .......... SUCCESS [ 12.668 s] > [INFO] WildFly: Subsystem Test POM ....................... SUCCESS [ 0.281 s] > [INFO] WildFly: Logging Subsystem ........................ SUCCESS [ 8.471 s] > [INFO] WildFly: JMX Subsystem ............................ SUCCESS [ 4.546 s] > [INFO] WildFly: Naming Subsystem ......................... SUCCESS [ 5.888 s] > [INFO] WildFly: Security Manager Subsystem ............... SUCCESS [ 5.096 s] > [INFO] WildFly: System JMX Module ........................ SUCCESS [ 0.690 s] > [INFO] WildFly: Threading Subsystem ...................... SUCCESS [ 2.348 s] > [INFO] WildFly: Server Build Tool ........................ SUCCESS [ 23.975 s] > [INFO] WildFly: Build Core ............................... SUCCESS [ 11.612 s] > [INFO] WildFly: EE ....................................... SUCCESS [ 8.572 s] > [INFO] WildFly: Clustering Subsystems .................... SUCCESS [ 0.063 s] > [INFO] WildFly: Common code for clustering subsystems .... SUCCESS [ 0.935 s] > [INFO] WildFly: JGroups Subsystem ........................ SUCCESS [ 2.217 s] > [INFO] WildFly: Clustering SPI ........................... SUCCESS [ 0.394 s] > [INFO] WildFly: JacORB Subsystem ......................... SUCCESS [ 9.209 s] > [INFO] WildFly: Transaction Subsystem .................... SUCCESS [ 4.364 s] > [INFO] WildFly: Infinispan Subsystem ..................... SUCCESS [ 5.407 s] > [INFO] WildFly: Security Subsystem parent ................ SUCCESS [ 0.067 s] > [INFO] WildFly: Security Subsystem ....................... SUCCESS [ 7.997 s] > [INFO] WildFly: Web Common Classes ....................... SUCCESS [ 5.203 s] > [INFO] WildFly: Undertow ................................. SUCCESS [ 4.476 s] > [INFO] WildFly: Build Web ................................ SUCCESS [ 5.849 s] > [INFO] WildFly: Connector Subsystem ...................... SUCCESS [ 11.943 s] > [INFO] WildFly: Clustering public API .................... SUCCESS [ 0.323 s] > [INFO] WildFly: SFSB clustering .......................... SUCCESS [ 0.075 s] > [INFO] WildFly: SFSB clustering - SPI .................... SUCCESS [ 0.400 s] > [INFO] WildFly: EJB Subsystem ............................ SUCCESS [ 12.775 s] > [INFO] WildFly: JPA Subsystem ............................ SUCCESS [ 9.119 s] > [INFO] WildFly: Web Subsystem ............................ SUCCESS [ 1.334 s] > [INFO] WildFly: Web Services Subsystem ................... SUCCESS [ 0.049 s] > [INFO] WildFly: Web Services Server Integration Subsystem SUCCESS [ 6.273 s] > [INFO] WildFly: Weld Integration ......................... SUCCESS [ 5.115 s] > [INFO] WildFly: PicketLink Subsystem ..................... SUCCESS [ 7.097 s] > [INFO] WildFly: Security Subsystem API ................... SUCCESS [ 0.450 s] > [INFO] WildFly: JAX-RS Integration ....................... SUCCESS [ 5.314 s] > [INFO] WildFly: RTS Subsystem ............................ SUCCESS [ 6.869 s] > [INFO] WildFly: Application Client Bootstrap ............. SUCCESS [ 2.534 s] > [INFO] WildFly: EJB Client BOM ........................... SUCCESS [ 0.136 s] > [INFO] WildFly: JMS Client BOM ........................... SUCCESS [ 0.251 s] > [INFO] WildFly: EJB and JMS client combined jar .......... SUCCESS [ 1.633 s] > [INFO] WildFly: SFSB clustering - Infinispan integration . SUCCESS [ 1.829 s] > [INFO] WildFly: Singleton service API .................... SUCCESS [ 0.346 s] > [INFO] WildFly: Clustering API implementation ............ SUCCESS [ 1.514 s] > [INFO] WildFly: Web session clustering ................... SUCCESS [ 0.051 s] > [INFO] WildFly: Web session clustering API ............... SUCCESS [ 0.303 s] > [INFO] WildFly: Web session clustering SPI ............... SUCCESS [ 0.362 s] > [INFO] WildFly: Web session clustering - Infinispan service provider SUCCESS [ 2.548 s] > [INFO] WildFly: Web session clustering - Undertow integration SUCCESS [ 0.741 s] > [INFO] WildFly: EJB Container Managed Persistence Subsystem SUCCESS [ 0.616 s] > [INFO] WildFly: Batch Integration ........................ SUCCESS [ 0.093 s] > [INFO] WildFly: JBeret Integration ....................... SUCCESS [ 2.633 s] > [INFO] WildFly: Batch Integration Subsystem .............. SUCCESS [ 0.951 s] > [INFO] WildFly: Deployment Scanner ....................... SUCCESS [ 1.527 s] > [INFO] WildFly: JAXR Client .............................. SUCCESS [ 0.550 s] > [INFO] WildFly: JBoss Diagnostic Reporter ................ SUCCESS [ 0.047 s] > [INFO] WildFly: JDR ...................................... SUCCESS [ 1.521 s] > [INFO] WildFly: JSF ...................................... SUCCESS [ 0.049 s] > [INFO] WildFly: JSF Subsystem ............................ SUCCESS [ 5.128 s] > [INFO] WildFly: JSF Injection Handlers ................... SUCCESS [ 2.175 s] > [INFO] WildFly: JSR-77 Subsystem ......................... SUCCESS [ 1.472 s] > [INFO] WildFly: Mail subsystem ........................... SUCCESS [ 1.768 s] > [INFO] WildFly: Messaging Subsystem ...................... SUCCESS [ 6.509 s] > [INFO] WildFly: mod_cluster Subsystem .................... SUCCESS [ 0.097 s] > [INFO] WildFly: mod_cluster Extension .................... SUCCESS [ 5.569 s] > [INFO] WildFly: mod_cluster Undertow Integration ......... SUCCESS [ 0.781 s] > [INFO] WildFly: POJO Subsystem ........................... SUCCESS [ 1.642 s] > [INFO] WildFly: Service Archive Subsystem ................ SUCCESS [ 1.047 s] > [INFO] WildFly: XTS Subsystem ............................ SUCCESS [ 5.802 s] > [INFO] WildFly: Build .................................... SUCCESS [01:07 min] > [INFO] WildFly: IO Subsystem tests ....................... SUCCESS [ 0.694 s] > [INFO] WildFly: Remoting Subsystem Test .................. SUCCESS [ 0.427 s] > [INFO] WildFly: Subsystem Test Framework Tests ........... SUCCESS [ 2.019 s] > [INFO] WildFly: Distribution ............................. SKIPPED > [INFO] WildFly: Arquillian ............................... SKIPPED > [INFO] WildFly: Arquillian TestEnricher MSC .............. SKIPPED > [INFO] WildFly: Arquillian Common ........................ SKIPPED > [INFO] WildFly: Arquillian Embedded Container ............ SKIPPED > [INFO] WildFly: Arquillian Protocol JMX .................. SKIPPED > [INFO] WildFly: Arquillian Managed Container ............. SKIPPED > [INFO] WildFly: Arquillian Remote Container .............. SKIPPED > [INFO] WildFly: Exported Java EE Specification APIs ...... SKIPPED > [INFO] WildFly: Arquillian TestNG Integration ............ SKIPPED > [INFO] WildFly: Arquillian Common Domain ................. SKIPPED > [INFO] WildFly: Arquillian Remote Domain Container ....... SKIPPED > [INFO] WildFly: Arquillian Managed Domain Container ...... SKIPPED > [INFO] WildFly: Core Model Test Controller 7.1.2 ......... SKIPPED > [INFO] WildFly: Core Model Test Controller 7.2.0 ......... SKIPPED > [INFO] WildFly: Core Model Test Controller Optional ...... SKIPPED > [INFO] WildFly: Core Model Tests ......................... SKIPPED > [INFO] WildFly: JSF Multi-JSF installer .................. SKIPPED > [INFO] WildFly: Validation Tests for Exported Java EE Specification APIs SKIPPED > [INFO] WildFly: Web Services Tests Integration Subsystem . SKIPPED > [INFO] WildFly Test Suite: Shared ........................ SKIPPED > [INFO] WildFly Test Suite: Aggregator .................... SKIPPED > [INFO] WildFly Test Suite: Integration ................... SKIPPED > [INFO] WildFly Test Suite: Integration - Smoke ........... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 19:29 min > [INFO] Finished at: 2014-06-17T18:20:54+00:00 > [INFO] Final Memory: 320M/742M > [INFO] ------------------------------------------------------------------------ > [ERROR] Java heap space -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError > Build step 'Execute shell' marked build as failure > Sending e-mails to: tom.jenkinson at redhat.com > release-narayana-current-inwildfly-AS800-tracker is disabled. Triggering skipped > Finished: FAILURE > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:59:05 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 08:59:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2153) QA suite failure with oracle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2153. ------------------------------- > QA suite failure with oracle > ---------------------------- > > Key: JBTM-2153 > URL: https://issues.jboss.org/browse/JBTM-2153 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/71/DB_TYPE=oracle,jdk=jdk7.latest,slave=linux/ -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:00:07 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:00:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2077) byteman and jfree jars incorrectly reported as required at runtime in pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2077: -------------------------------- Fix Version/s: 5.0.0 > byteman and jfree jars incorrectly reported as required at runtime in pom.xml > ----------------------------------------------------------------------------- > > Key: JBTM-2077 > URL: https://issues.jboss.org/browse/JBTM-2077 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.0 > > > The jars mentioned above are not required at runtime so should not be present as such in the pom.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:00:07 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:00:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2091) Narayana 5.0.0.Final Release Notes page broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2091. ------------------------------- > Narayana 5.0.0.Final Release Notes page broken > ---------------------------------------------- > > Key: JBTM-2091 > URL: https://issues.jboss.org/browse/JBTM-2091 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: David Hladky > Assignee: Tom Jenkinson > > Hi, we received following ticket: https://engineering.redhat.com/rt/Ticket/Display.html?id=275511 > Original text: > I was attempting to look at the release notes for Narayana 5.0.0.Final and I am getting a Page Not Found error. http://docs.jboss.org/jbosstm/5.0.0.Final/guides/release_notes/index.html -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:02:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:02:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2077) byteman and jfree jars incorrectly reported as required at runtime in pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2077. ------------------------------- > byteman and jfree jars incorrectly reported as required at runtime in pom.xml > ----------------------------------------------------------------------------- > > Key: JBTM-2077 > URL: https://issues.jboss.org/browse/JBTM-2077 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.0 > > > The jars mentioned above are not required at runtime so should not be present as such in the pom.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:02:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:02:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2236) Remove / from ConfigurationInfo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2236. ------------------------------- > Remove / from ConfigurationInfo > ------------------------------- > > Key: JBTM-2236 > URL: https://issues.jboss.org/browse/JBTM-2236 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Common > Affects Versions: 5.0.2 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.0.3 > > > I've been working on compiling Java using the Avian project (http://oss.readytalk.com/avian/) and have eventually had success in running some of our hammer tests. However, there was a blocker which was to do with the way in which we locate the property file within the jar using the manifest. We can argue as to whether the issue resides within Avian or the way in which we do things, but the solution was to simply remove the / from: > int suffixLength = ("/"+ConfigurationInfo.class.getCanonicalName()+".class").length(); > Rebuilding and rerunning the tests made everything work. > I don't want to check in this change until I am sure that it is right, so would appreciate someone looking at it and at least running all of the QE tests to be sure nothing else breaks. > I've included a reference to the Avian forum article where I discussed this with their team. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:02:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:02:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2231) Detailed TRACE logging for Synchronization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2231. ------------------------------- > Detailed TRACE logging for Synchronization > ------------------------------------------ > > Key: JBTM-2231 > URL: https://issues.jboss.org/browse/JBTM-2231 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Fix For: 5.0.3 > > > Provide TRACE logging of Synchronization interactions. > * Adding Synchronization through registerSynchronization > * Adding Synchronization through registerInterposedSynchronization > * Call of beforeCompletion > * Call of afterCompletion > Each TRACE statement needs > * Class name > * Identity hash code > * toString -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:18:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Sep 2014 09:18:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2252) QA suite failure: CrashRecovery05_2_Test030 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2252: ----------------------------------- Attachment: CrashRecovery05_2_Test030.tar > QA suite failure: CrashRecovery05_2_Test030 > -------------------------------------------- > > Key: JBTM-2252 > URL: https://issues.jboss.org/browse/JBTM-2252 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.0.4 > > Attachments: CrashRecovery05_2_Test030.tar > > > http://172.17.131.2/view/Status/job/narayana/638/PROFILE=QA_JTS_JACORB,jdk=jdk7.latest,label=linux -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:37:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:37:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2237) Ensure that narayana-jts-idlj is uploaded to nexus as part of the release In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2237. --------------------------------- Resolution: Done > Ensure that narayana-jts-idlj is uploaded to nexus as part of the release > ------------------------------------------------------------------------- > > Key: JBTM-2237 > URL: https://issues.jboss.org/browse/JBTM-2237 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:42:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:42:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2216) Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2216. --------------------------------- Resolution: Done Resolved in https://github.com/jbosstm/narayana/commit/18f1884ee15da0c2ec6a2a33e2bdacd1f8187cca > Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed > ----------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2216 > URL: https://issues.jboss.org/browse/JBTM-2216 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.17.20, 4.17.21, 5.0.2 > Environment: JBoss EAP 6.3 > Reporter: Tom Ross > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > When using AMQ failover protocol, the Narayana recovery process generates the following exception: > {noformat} > 10:19:36,053 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true > 10:21:46,139 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true > 10:21:46,139 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Failover transport not connected: unconnected > at org.apache.activemq.TransactionContext.recover(TransactionContext.java:656) > at org.apache.activemq.ra.LocalAndXATransaction.recover(LocalAndXATransaction.java:135) > at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.recover(XAResourceWrapperImpl.java:177) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:548) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:187) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > 10:21:56,165 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:619) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > {noformat} > Although the first message may be expected if the resource manager throws an exception in XAResource::recover(), the second message does not add any further assistance in resolving the issue and should be removed as noise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:43:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:43:02 -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: -------------------------------- Assignee: (was: Tom Jenkinson) > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Student project > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > > 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.3.1#6329) From issues at jboss.org Mon Sep 15 09:45:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:45:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2189) Bootstrapping from Complex Classloader (OneJar) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2189. --------------------------------- Resolution: Incomplete Description Hi Chris, As per my comment earlier in the year, I am going to have to close this issue as incomplete. Thanks for your interest and please do feel free to complete the details and re-open. Tom > Bootstrapping from Complex Classloader (OneJar) > ----------------------------------------------- > > Key: JBTM-2189 > URL: https://issues.jboss.org/browse/JBTM-2189 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Common > Affects Versions: 5.0.1 > Environment: JDK 8, OneJar 0.97 > Reporter: Chris Pheby > Assignee: Tom Jenkinson > > I am using Narayana within a JavaSE application. The application is compiled into a single Jar. When executing, Narayana fails to bootstrap properly. > The first problem is within com.arjuna.common.util.ConfigurationInfo. > Lines 111-115 aim to load the MANIFEST file from the classpath: > String pathToManifest = basePath+"/META-INF/MANIFEST.MF"; > InputStream is = null; > try { > is = new URL(pathToManifest).openStream(); > I replaced this with: > InputStream is = null; > // BEGIN - WORKAROUND FOR ONE-JAR > try { > String targetPrefix = pathToThisClass.substring(0, pathToThisClass.length() - "/com/arjuna/common/util/ConfigurationInfo.class".length()); > Enumeration resources = ConfigurationInfo.class.getClassLoader().getResources("META-INF/MANIFEST.MF"); > while (resources.hasMoreElements()) { > URL next = resources.nextElement(); > if (next.toString().startsWith(targetPrefix)) { > is = next.openStream(); > break; > } > } > // END - WORKAROUND FOR ONE-JAR > This should work for all environments. > Changes are also required in com.arjuna.common.util.propertyservice.AbstractPropertiesFactory to attempt loading from classpath as well as file system: > The last line of initDefaultProperties (195) needed changing to: > defaultProperties = getPropertiesFromClasspath(propertyFileName, PropertiesFactoryStax.class.getClassLoader()); > if (defaultProperties == null) { > defaultProperties = getPropertiesFromFile(propertyFileName, PropertiesFactoryStax.class.getClassLoader()); > } > } > and the following methods added / replaced: > /** > * Returns the config properties read from a specified relative location on the classpath. > * > * @param propertyFileName the file name relative to the classpath root. > * @return the Properties loaded from the specified source. > */ > public Properties getPropertiesFromClasspath(String propertyFileName, ClassLoader classLoader) { > Properties properties = null; > > try { > Enumeration resources = ConfigurationInfo.class.getClassLoader().getResources(propertyFileName); > while (resources.hasMoreElements()) { > URL next = resources.nextElement(); > > properties = loadFromStream(next.openStream()); > return properties; > } > } catch(Exception e) { > return null; > } > return properties; > } > > /** > * Returns the config properties read from a specified location. > * > * @param propertyFileName the file name. If relative, this is located using the FileLocator algorithm. > * @return the Properties loaded from the specified source. > */ > public Properties getPropertiesFromFile(String propertyFileName, ClassLoader classLoader) { > String propertiesSourceUri = null; > try > { > // This is the point where the search path is applied - user.dir (pwd), user.home, java.home, classpath > propertiesSourceUri = com.arjuna.common.util.propertyservice.FileLocator.locateFile(propertyFileName, classLoader); > } > catch(FileNotFoundException fileNotFoundException) > { > // try falling back to a default file built into the .jar > // Note the default- prefix on the name, to avoid finding it from the .jar at the previous stage > // in cases where the .jar comes before the etc dir on the classpath. > URL url = AbstractPropertiesFactory.class.getResource("/default-"+propertyFileName); > if(url == null) { > throw new RuntimeException("missing property file "+propertyFileName); > } else { > propertiesSourceUri = url.toString(); > } > } > catch (IOException e) > { > throw new RuntimeException("invalid property file "+propertiesSourceUri, e); > } > Properties properties = null; > try { > properties = loadFromFile(propertiesSourceUri); > properties = applySystemProperties(properties); > } catch(Exception e) { > throw new RuntimeException("unable to load properties from "+propertiesSourceUri, e); > } > return properties; > } > private Properties loadFromStream(InputStream inputStream) throws IOException { > Properties inputProperties = new Properties(); > Properties outputProperties = new Properties(); > try { > loadFromXML(inputProperties,inputStream); > } finally { > inputStream.close(); > } > Enumeration namesEnumeration = inputProperties.propertyNames(); > while(namesEnumeration.hasMoreElements()) { > String propertyName = (String)namesEnumeration.nextElement(); > String propertyValue = inputProperties.getProperty(propertyName); > propertyValue = propertyValue.trim(); > // perform JBossAS style property substitutions. JBTM-369 > propertyValue = StringPropertyReplacer.replaceProperties(propertyValue); > outputProperties.setProperty(propertyName, propertyValue); > } > return outputProperties; > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:45:05 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:45:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2150) Update narayana.sh and narayana-quickstarts/config to not require WILDFLY_MASTER_VERSION In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2150. --------------------------------- Resolution: Won't Fix > Update narayana.sh and narayana-quickstarts/config to not require WILDFLY_MASTER_VERSION > ---------------------------------------------------------------------------------------- > > Key: JBTM-2150 > URL: https://issues.jboss.org/browse/JBTM-2150 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > They should be able to infer this from the projects own pom files. > For narayana.sh it is in /pom.xml: > 8.0.1.Final-SNAPSHOT > For narayana-quickstart/config it is in (for example) ./XTS/wsat-jta-multi_service/pom.xml: > 8.0.1.Final-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:46:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:46:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1763) Consider running the QA tests in parrallel In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1763: -------------------------------- Fix Version/s: (was: 6.0.0) > Consider running the QA tests in parrallel > ------------------------------------------ > > Key: JBTM-1763 > URL: https://issues.jboss.org/browse/JBTM-1763 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > > The QA tests currently take 5hrs to run per orb. This constitutes 83% of our CI run time. > My understanding is that the time is mostly taken up in Thread.sleep. The test times range from 1 to 99seconds. So there are no major hotspots. The problem is that there are so many tests. > I suspect we could run these tests in parallel to make better utilisation of resources. > The tests don't run in an AS, but they do acquire ports. There may be other restrictions that make running them in parallel hard or impossible. > It would be easier to simply carve up the tests into, say 5 parts per orb and have CI do the parallelism. However, this will consume more CI nodes than if we ran them in parallel on a single node. > I think it would be worth investigating if we can run the tests in n batches (say n=10 initially, but should be configurable). Where each batch runs with a different port configuration. This may prove too disruptive to the tests, > and also more bother than it is worth. Maybe we could do an initial investigation to see if this has legs? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:47:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:47:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1763) Consider running the QA tests in parrallel In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-1763. --------------------------------- Resolution: Won't Fix Although it might be useful, we do not have any intention of doing this at this time and there are alternatives such as job config that could do this. > Consider running the QA tests in parrallel > ------------------------------------------ > > Key: JBTM-1763 > URL: https://issues.jboss.org/browse/JBTM-1763 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > > The QA tests currently take 5hrs to run per orb. This constitutes 83% of our CI run time. > My understanding is that the time is mostly taken up in Thread.sleep. The test times range from 1 to 99seconds. So there are no major hotspots. The problem is that there are so many tests. > I suspect we could run these tests in parallel to make better utilisation of resources. > The tests don't run in an AS, but they do acquire ports. There may be other restrictions that make running them in parallel hard or impossible. > It would be easier to simply carve up the tests into, say 5 parts per orb and have CI do the parallelism. However, this will consume more CI nodes than if we ran them in parallel on a single node. > I think it would be worth investigating if we can run the tests in n batches (say n=10 initially, but should be configurable). Where each batch runs with a different port configuration. This may prove too disruptive to the tests, > and also more bother than it is worth. Maybe we could do an initial investigation to see if this has legs? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:49:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:49:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2055) Add testing on WELD container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2055: -------------------------------- Fix Version/s: (was: 6.0.0) > Add testing on WELD container > ----------------------------- > > Key: JBTM-2055 > URL: https://issues.jboss.org/browse/JBTM-2055 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:49:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:49:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2055) Add testing on WELD container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2055. --------------------------------- Resolution: Incomplete Description > Add testing on WELD container > ----------------------------- > > Key: JBTM-2055 > URL: https://issues.jboss.org/browse/JBTM-2055 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:50:05 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:50:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1939) Consider using awestruct to develop http://narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1939: -------------------------------- Assignee: Gytis Trikleris (was: Tom Jenkinson) > Consider using awestruct to develop http://narayana.io > ------------------------------------------------------ > > Key: JBTM-1939 > URL: https://issues.jboss.org/browse/JBTM-1939 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > > Awestruct appears to be a powerful and flexible tool to develop websites with. This task is to research the capabilities of the tool and determine if the benefits of awestruct apply to our website. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:51:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:51:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1954) Nothing is archived if CI job jbossts-EAP61-jdbcobjectstore fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-1954. --------------------------------- Resolution: Cannot Reproduce Bug It may be the case but it could have been an issue with the version of Jenkins too. Closing until we see it happen again. > Nothing is archived if CI job jbossts-EAP61-jdbcobjectstore fails > ----------------------------------------------------------------- > > Key: JBTM-1954 > URL: https://issues.jboss.org/browse/JBTM-1954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > > If an axis of CI job jbossts-EAP61-jdbcobjectstore fails no files are archived. > The job config looks perfectly fine and the files are archived if the job is successful so maybe this is a Jenkins bug to do with multi-axis jobs. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:51:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:51:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1954) Nothing is archived if CI job jbossts-EAP61-jdbcobjectstore fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-1954. ------------------------------- > Nothing is archived if CI job jbossts-EAP61-jdbcobjectstore fails > ----------------------------------------------------------------- > > Key: JBTM-1954 > URL: https://issues.jboss.org/browse/JBTM-1954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > > If an axis of CI job jbossts-EAP61-jdbcobjectstore fails no files are archived. > The job config looks perfectly fine and the files are archived if the job is successful so maybe this is a Jenkins bug to do with multi-axis jobs. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 09:56:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 09:56:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2148) Consider handling RuntimeExceptions arising from badly behaved XAResource implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2148. --------------------------------- Resolution: Won't Fix I don't think it is sustainable to add support for this but if our community thinks it beneficial we can re-open. > Consider handling RuntimeExceptions arising from badly behaved XAResource implementations > ----------------------------------------------------------------------------------------- > > Key: JBTM-2148 > URL: https://issues.jboss.org/browse/JBTM-2148 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 4.17.19, 5.0.1 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > It has been observed that some XAResource implementations throw RuntimeExceptions from their XAResource::end method. > Although this is not spec compliant, it does mean that the transaction will never complete and as such afterCompletion would never be called, nor would we attempt to complete the remaining branches in the transaction. > In ArjunaCore terms the transaction would be left in the state of ActionStatus.ABORTING. > This Jira exists as a possible route for users to vote for addressing this issue. One possibility would be to try to align a RuntimeException with a response of XAResource.XA_RETRY where possible. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:02:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:02:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2184) NoClassDefFoundError: Missing Dependency on jboss-transaction-spi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2184: -------------------------------- Fix Version/s: (was: 5.0.4) > NoClassDefFoundError: Missing Dependency on jboss-transaction-spi > ----------------------------------------------------------------- > > Key: JBTM-2184 > URL: https://issues.jboss.org/browse/JBTM-2184 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.1 > Reporter: Andrew Rubinger > Assignee: Tom Jenkinson > > Looks like Narayana is missing a dependency, as this isn't brought in transitively: > {code}java.lang.NoClassDefFoundError: org/jboss/tm/FirstResource > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.order(XAResourceRecord.java:139) > at com.arjuna.ats.arjuna.coordinator.AbstractRecord.orderEquals(AbstractRecord.java:663) > at com.arjuna.ats.arjuna.coordinator.AbstractRecord.equals(AbstractRecord.java:227) > at com.arjuna.ats.arjuna.coordinator.RecordList.insert(RecordList.java:379) > at com.arjuna.ats.arjuna.coordinator.RecordList.insert(RecordList.java:144) > at com.arjuna.ats.arjuna.coordinator.BasicAction.add(BasicAction.java:307) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:647){code} > I'm also not finding the 7.x series of jboss-transaction-spi in Maven Central; is this intended? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:03:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2184) NoClassDefFoundError: Missing Dependency on jboss-transaction-spi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2184. --------------------------------- Resolution: Cannot Reproduce Bug I am closing this as I can't reproduce it with the ArjunaJTA/maven quickstart: {quote} [tom at TOM-PC ~](14:37:24) $ cd projects/jbosstm/quickstart/ArjunaJTA/maven/ [tom at TOM-PC maven](master)(14:37:24) $ mvn exec:exec [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building basic maven example 5.0.4.Final-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- exec-maven-plugin:1.2:exec (default-cli) @ maven --- Sep 15, 2014 3:02:02 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 49387 Sep 15, 2014 3:02:02 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 49387 Sep 15, 2014 3:02:02 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start INFO: ARJUNA012170: TransactionStatusManager started on port 49387 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService TransactionImple < ac, BasicAction: 0:ffff0a037014:c0ec:5416f15a:2 status: ActionStatus.RUNNING > null [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.602 s [INFO] Finished at: 2014-09-15T15:02:02+01:00 [INFO] Final Memory: 9M/303M [INFO] ------------------------------------------------------------------------ {quote} > NoClassDefFoundError: Missing Dependency on jboss-transaction-spi > ----------------------------------------------------------------- > > Key: JBTM-2184 > URL: https://issues.jboss.org/browse/JBTM-2184 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.1 > Reporter: Andrew Rubinger > Assignee: Tom Jenkinson > > Looks like Narayana is missing a dependency, as this isn't brought in transitively: > {code}java.lang.NoClassDefFoundError: org/jboss/tm/FirstResource > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.order(XAResourceRecord.java:139) > at com.arjuna.ats.arjuna.coordinator.AbstractRecord.orderEquals(AbstractRecord.java:663) > at com.arjuna.ats.arjuna.coordinator.AbstractRecord.equals(AbstractRecord.java:227) > at com.arjuna.ats.arjuna.coordinator.RecordList.insert(RecordList.java:379) > at com.arjuna.ats.arjuna.coordinator.RecordList.insert(RecordList.java:144) > at com.arjuna.ats.arjuna.coordinator.BasicAction.add(BasicAction.java:307) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:647){code} > I'm also not finding the 7.x series of jboss-transaction-spi in Maven Central; is this intended? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:14:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:14:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2182) [quickstart] NoClassDefFoundError on ArjunaJTA/maven In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2182. --------------------------------- Resolution: Done Resolved in https://github.com/jbosstm/quickstart/commit/daa819a176ade22ae75c1e05e127b4d9257c83ae > [quickstart] NoClassDefFoundError on ArjunaJTA/maven > ---------------------------------------------------- > > Key: JBTM-2182 > URL: https://issues.jboss.org/browse/JBTM-2182 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Andrew Rubinger > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > [INFO] --- exec-maven-plugin:1.2:exec (default-cli) @ maven --- > Exception in thread "main" java.lang.RuntimeException: java.lang.NoClassDefFoundError: Ljavax/transaction/TransactionManager; > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:81) > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49) > at com.arjuna.ats.jta.common.jtaPropertyManager.getJTAEnvironmentBean(jtaPropertyManager.java:42) > at com.arjuna.ats.jta.TransactionManager.transactionManager(TransactionManager.java:71) > at TransactionManagerExample.main(TransactionManagerExample.java:39) > Caused by: java.lang.NoClassDefFoundError: Ljavax/transaction/TransactionManager; > at java.lang.Class.getDeclaredFields0(Native Method) > at java.lang.Class.privateGetDeclaredFields(Class.java:2570) > at java.lang.Class.getDeclaredFields(Class.java:1903) > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:135) > at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:78) > ... 4 more > Caused by: java.lang.ClassNotFoundException: javax.transaction.TransactionManager > at java.net.URLClassLoader$1.run(URLClassLoader.java:372) > at java.net.URLClassLoader$1.run(URLClassLoader.java:361) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:360) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 9 more > Probably due to Tx API being in provided scope, not included in exec:exec under src/java/main? > [INFO] +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:provided > Also: NCDFE in javax_transaction/TransactionExample: > Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logging/Logger > Probably wanna audit the whole module; is this not tested in CI? Would suggest re-implementing perhaps as unit tests instead of Main classes. > From Mike: It gets run under CI regularly (and the last build was on 22-May-2014 16:13:23). I can't remember the last time it failed. You should be able to just check out the repo and type mvn clean install from the top > From Tom: I said that we might not run exec:exec in CI as some of the QS are quite intricate and difficult to script. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:21:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:21:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2055) Add testing on WELD container In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2055. ------------------------------- > Add testing on WELD container > ----------------------------- > > Key: JBTM-2055 > URL: https://issues.jboss.org/browse/JBTM-2055 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:21:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:21:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1763) Consider running the QA tests in parrallel In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-1763. ------------------------------- > Consider running the QA tests in parrallel > ------------------------------------------ > > Key: JBTM-1763 > URL: https://issues.jboss.org/browse/JBTM-1763 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > > The QA tests currently take 5hrs to run per orb. This constitutes 83% of our CI run time. > My understanding is that the time is mostly taken up in Thread.sleep. The test times range from 1 to 99seconds. So there are no major hotspots. The problem is that there are so many tests. > I suspect we could run these tests in parallel to make better utilisation of resources. > The tests don't run in an AS, but they do acquire ports. There may be other restrictions that make running them in parallel hard or impossible. > It would be easier to simply carve up the tests into, say 5 parts per orb and have CI do the parallelism. However, this will consume more CI nodes than if we ran them in parallel on a single node. > I think it would be worth investigating if we can run the tests in n batches (say n=10 initially, but should be configurable). Where each batch runs with a different port configuration. This may prove too disruptive to the tests, > and also more bother than it is worth. Maybe we could do an initial investigation to see if this has legs? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:21:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:21:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2150) Update narayana.sh and narayana-quickstarts/config to not require WILDFLY_MASTER_VERSION In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2150. ------------------------------- > Update narayana.sh and narayana-quickstarts/config to not require WILDFLY_MASTER_VERSION > ---------------------------------------------------------------------------------------- > > Key: JBTM-2150 > URL: https://issues.jboss.org/browse/JBTM-2150 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > They should be able to infer this from the projects own pom files. > For narayana.sh it is in /pom.xml: > 8.0.1.Final-SNAPSHOT > For narayana-quickstart/config it is in (for example) ./XTS/wsat-jta-multi_service/pom.xml: > 8.0.1.Final-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:38:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:38:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-1341: --------------------------------- For backport, I will do it but leaving assignee > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:38:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:38:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1341: -------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/186, https://github.com/jbosstm/narayana/pull/726 (was: https://github.com/jbosstm/narayana/pull/186) > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:38:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Sep 2014 10:38:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1341: -------------------------------- Fix Version/s: 4.17.23 > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 10:39:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 15 Sep 2014 10:39:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-1341: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1139102 > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 11:37:03 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Sep 2014 11:37:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2251) Replace killall with pkill in the CI build script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2251: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Replace killall with pkill in the CI build script > ------------------------------------------------- > > Key: JBTM-2251 > URL: https://issues.jboss.org/browse/JBTM-2251 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > Some of our CI machines are missing killall which is non-standard. Replace it with pkill. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 08:47:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Sep 2014 08:47:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2255: ------------------------------------- Summary: Do not return StatusCommiting, if transaction was commited by the original transaction manager Key: JBTM-2255 URL: https://issues.jboss.org/browse/JBTM-2255 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 4.17.23 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 08:49:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 16 Sep 2014 08:49:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2255: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080035 > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 09:20:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Sep 2014 09:20:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/727 > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 09:26:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Sep 2014 09:26:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Description: We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. However, as shown by the attached bugzilla, following work flow is still possible: > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, following work flow is still possible: -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 09:29:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Sep 2014 09:29:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Description: We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. was: We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. However, as shown by the attached bugzilla, following work flow is still possible: > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 10:56:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 16 Sep 2014 10:56:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-1341. ------------------------------- Resolution: Done > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 15:16:17 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 16 Sep 2014 15:16:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2229) Issue with issue recovering AA with CMR, recovers OK but via orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003203#comment-13003203 ] RH Bugzilla Integration commented on JBTM-2229: ----------------------------------------------- Paul Gier changed the Status of [bug 1124861|https://bugzilla.redhat.com/show_bug.cgi?id=1124861] from MODIFIED to ON_QA > Issue with issue recovering AA with CMR, recovers OK but via orphan detection > ----------------------------------------------------------------------------- > > Key: JBTM-2229 > URL: https://issues.jboss.org/browse/JBTM-2229 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.21, 5.0.2 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.22, 5.0.3 > > > The issue is with the CMR recovery module when it needs to update the underlying AA to modify it with the correct value from the CMR XIDS table. > If this AA does not have Serializable XARs, it will lead to the Xid being removed from XARM during getNewXAResource (via restore_state of the XARR). When the later AARM tries to recover the AA, it means a corresponding XAR for the XID cannot be located in the XARM by the XARR and an error message is reported. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 10:37:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Sep 2014 10:37:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 11:20:03 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 17 Sep 2014 11:20:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003526#comment-13003526 ] Mark Little commented on JBTM-2255: ----------------------------------- Unfortunately this change is not guaranteed to work in all situations. You are assuming that GenericRecoveryCoordinator is a local instance to the transaction manager/coordinator but it isn't. This comes from the OTS specification and if you run through the various ways in which the status variable can be set (at the start of the method) you'll see that a) it can be remote from the coordinator and b) the status may even be obtained remotely. So there's a very good chance that BasicAction information isn't available to the GenericRecoveryCoordinator because it simply isn't in the same process. > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 13:04:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Sep 2014 13:04:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2256: ------------------------------------- Summary: Race condition between recovery manager initialization and expiry scanner Key: JBTM-2256 URL: https://issues.jboss.org/browse/JBTM-2256 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 4.17.23, 5.0.4 In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time. Personally I couldn't reproduce the problem. Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 13:05:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Sep 2014 13:05:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2256: ---------------------------------- Description: In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. Swapping these two actions should solve the problem. was:In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time. Personally I couldn't reproduce the problem. Swapping these two actions should solve the problem. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 13:05:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 17 Sep 2014 13:05:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2256: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1104584 > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 13:12:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Sep 2014 13:12:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2256: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/728, https://github.com/jbosstm/narayana/pull/729 > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 02:31:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 18 Sep 2014 02:31:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003703#comment-13003703 ] Mark Little commented on JBTM-2256: ----------------------------------- If you can't reproduce it then you're just going by looking through the code? Would be better if we had something that reproduced. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 02:56:02 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 18 Sep 2014 02:56:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2257) Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: Message-ID: Amos Feng created JBTM-2257: ------------------------------- Summary: Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT Key: JBTM-2257 URL: https://issues.jboss.org/browse/JBTM-2257 Project: JBoss Transaction Manager Issue Type: Task Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.0.4 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 03:00:05 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 18 Sep 2014 03:00:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2257) Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2257: ---------------------------- Component/s: Application Server Integration > Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT > ----------------------------------------------------- > > Key: JBTM-2257 > URL: https://issues.jboss.org/browse/JBTM-2257 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 03:00:04 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 18 Sep 2014 03:00:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2257) Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2257: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/730 > Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT > ----------------------------------------------------- > > Key: JBTM-2257 > URL: https://issues.jboss.org/browse/JBTM-2257 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 04:10:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 18 Sep 2014 04:10:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003746#comment-13003746 ] Mark Little commented on JBTM-2255: ----------------------------------- StatusChecker.getStatus checks the object store (see bottom of method) using getStatus on the OTS factory if instance isn't running. Make sure that checks the object store location where logs may be moved in the event of assumed complete scanner going off. > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 04:12:03 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 18 Sep 2014 04:12:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003748#comment-13003748 ] Mark Little commented on JBTM-2255: ----------------------------------- TransactionFactoryImple.getOSStatus > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 04:16:03 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 18 Sep 2014 04:16:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Little reopened JBTM-2255: ------------------------------- > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 05:28:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 18 Sep 2014 05:28:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003777#comment-13003777 ] Gytis Trikleris commented on JBTM-2256: --------------------------------------- Me and Tom went through the stack trace and the code and this was the only cause we could find. However, I can confirm that not adding ExtendedXAResourceRecordMap to the record types map causes expiry scanner to throw java.lang.InstantiationException. It is because AbstractRecord class is used as a default type, if the requested type does not exist. And in such case Class.newInstance() call will always fail, since it is an abstract class. Swapping places of those two lines assures that ExtendedXAResourceRecordMap is added to the record types map before expiry scanner is started. On the other hand, the main reason of this pull request was to check if it doesn't cause our qa tests to fail. I will contact people who raised the bugzilla, to confirm that this issue is fixed, since they can reproduce the error without modifying the code. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 05:39:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Sep 2014 05:39:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003788#comment-13003788 ] Tom Jenkinson commented on JBTM-2256: ------------------------------------- Hi Gytis, The way to reproduce the bug is to put a breakpoint here: https://github.com/Gytis/narayana/blob/4.17/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/RecoveryManagerImple.java#L113 If you do that and you have a scanner configured and that needs to create an abstract record of say type 172 (for example, as the ExpiredAssumedCompleteScanner in the linked BZ may need to), it will fail. This is a reproducer I have to verify it: https://github.com/tomjenkinson/narayana/compare/4.17...JBTM-2256 You need to add the breakpoint in RecoveryManagerImple after it has started the expiry scanner but before it loads the recovery modules (line 113 above). You can also add a breakpoint in the reproducer class on "AbstractRecord.create(172);" If you allow the AbstractRecord.create(172); before you release the RecoveryManagerImple you will see: {quote} java.lang.InstantiationException at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at com.arjuna.ats.arjuna.coordinator.AbstractRecord.create(AbstractRecord.java:446) at com.hp.mwtests.ts.jta.jts.recovery.RecoveryManagerUnitTest$1.scan(RecoveryManagerUnitTest.java:41) at com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.run(ExpiredEntryMonitor.java:171) {quote} Swapping the lines does not allow this scenario to occur. I think you should add a comment into your fix to provide more details on this so it is not swapped back in the future. Tom > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 06:05:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 18 Sep 2014 06:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2241: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1143947 > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 06:21:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 18 Sep 2014 06:21:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2241: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1143947, https://bugzilla.redhat.com/show_bug.cgi?id=1143956 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1143947) > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 22:50:02 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 18 Sep 2014 22:50:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2257) Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2257: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade Narayana to use Wildfly 9.0.0.Alpha2-SNAPSHOT > ----------------------------------------------------- > > Key: JBTM-2257 > URL: https://issues.jboss.org/browse/JBTM-2257 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 08:06:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 19 Sep 2014 08:06:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004261#comment-13004261 ] Mark Little commented on JBTM-2256: ----------------------------------- Sounds like something Byteman could help with here. We should definitely add an automatic test for this into the test suite to ensure that any fix is appropriate and this case is covered in the future. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 09:36:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 19 Sep 2014 09:36:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/jbosstm/narayana/pull/732 (was: https://github.com/jbosstm/narayana/pull/727) > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:26:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 19 Sep 2014 10:26:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004330#comment-13004330 ] Tom Jenkinson commented on JBTM-2256: ------------------------------------- Implementing the fix will prevent us creating a byteman race condition test case for the issue as it will (assuming the correct recovery modules are configured) no longer be possible for the expiry scanner to start before the Implementationsx.java is loaded. A comment in the code that explains the issue (i.e. ExpiredEntryMonitor.startUp(); _MUST_ be called after _periodicRecovery = new PeriodicRecovery(threaded, useListener); and provide more details on that) is the best thing to ensure its not reverted, plus Gytis should also cherry-pick the test I have written https://github.com/tomjenkinson/narayana/compare/4.17...JBTM-2256 during verification of the issue. Even though Byteman verification isn't possible, the test could still alert us if something were to change in this area in the future. On the link I provided above you will see that I have added byteman to verify the failure without the fix. Once the fix is applied the test will hand as the race condition no longer exists so that specific commit should not be cherry-picked but the underlying test can be. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1715) NPE when using CompensationManager within an in-flowed WS-BA transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1715: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > NPE when using CompensationManager within an in-flowed WS-BA transaction > ------------------------------------------------------------------------ > > Key: JBTM-1715 > URL: https://issues.jboss.org/browse/JBTM-1715 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction. > {quote} > 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100] > ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS > HOT] > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1507) Review the TXBridge tests usage of Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1507: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > Review the TXBridge tests usage of Arquillian > --------------------------------------------- > > Key: JBTM-1507 > URL: https://issues.jboss.org/browse/JBTM-1507 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Testing, TxBridge > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The TXBridge tests don;t seem to be using Arquillian correctly. There is a servlet that is invoked to do things inside the container. As the tests (should) now run in the container, this should not be needed. > The tests also seem to have added complexity due to the recovery tests. As the recovery tests need to be able to kill the container, it mandates manual container lifecycle management for *all* tests. We may want to pull out the recovery tests into a separate module. > We also may want to pull out the DisabledContextPropagationTest into a separate module as they use a modified AS configuration. > We should also take a general look at how the tests are structured and using Arq. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1680) Allow 2PC participants to enlist in a compensation-based transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1680: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > Allow 2PC participants to enlist in a compensation-based transaction > -------------------------------------------------------------------- > > Key: JBTM-1680 > URL: https://issues.jboss.org/browse/JBTM-1680 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > In some situations a developer may need to coordinate multiple resources, where some are 2PC and some are not. Here it could be possible to use enlist the 2PC participants in a compensation-based transaction. The xa.prepare happens in the complete phase, the xa.commit during close and xa.rollback during compensate. > This could provide an alternative to LRCO, where the last resource is compensation-based and the other resources remain 2PC. The benefit of this approach is that the failure window associated with LRCO does not exist. The negative of this approach is that the isolation of the compensation-based participant is reduced. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1639) Improve XTS Api for looking up Recovery Manager to prevent developer from poling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1639: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > Improve XTS Api for looking up Recovery Manager to prevent developer from poling > -------------------------------------------------------------------------------- > > Key: JBTM-1639 > URL: https://issues.jboss.org/browse/JBTM-1639 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Fix For: 6.0.0 > > > Currently the developer needs to poll for the RecoveryManager as it's possible that the application can be deployed before the XTS subsystem has finished startup. > This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the application poll until the RM was not null. > Two possible solutions: > Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return until there is an RM available. if we use the existing java method, we need to analyse all usages to make sure returning null is not a valid outcome. > Another solution is to find out how to delay the application's initialisation until after XTS has started. This puts the burden on the application developer to implement, but requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for initialising the application. I tried three and none of them fired after the server had booted. > To Reproduce > Put breakpoints on: > Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all threads > XTSATRecoveryManager.setRecoveryManager() // stop on Thread only > Copy your application to the deploy directory (xtstest.war is a good choice). Now start the server with debugging enabled (suspend=y). To reproduce this you will see the XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to continue and you will notice it is null. Fix this problem, and the getRecoveryManager will wait until the setRecoveryManager is complete and thus always return a non-null RM. > Once this is fixed, find all occurrence of the polling work-around and have them use the solution to this issue. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1859) Remove classname Strings from XTS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1859: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > Remove classname Strings from XTS subsystem > ------------------------------------------- > > Key: JBTM-1859 > URL: https://issues.jboss.org/browse/JBTM-1859 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, XTS > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe. > When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details. > However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName(). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2213) Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2213: -------------------------------- Reporter: Gytis Trikleris (was: Tom Jenkinson) > Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba > ------------------------------------------------------------------------------------------ > > Key: JBTM-2213 > URL: https://issues.jboss.org/browse/JBTM-2213 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Affects Versions: 5.0.2 > Reporter: Gytis Trikleris > Assignee: Paul Robinson > > If you run: > ./build.sh clean install -DskipTests | grep "org.jboss.narayana.txframework.api.annotation.lifecycle.ba" > You will see: > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipant.java:[45,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[112,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[154,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[115,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[162,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[57,146] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[115,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[158,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[62,27] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[65,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[118,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[166,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-396) Provide one-phase commit optimization for WS-TX In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-396: ------------------------------- Reporter: Gytis Trikleris (was: Mark Little) > Provide one-phase commit optimization for WS-TX > ----------------------------------------------- > > Key: JBTM-396 > URL: https://issues.jboss.org/browse/JBTM-396 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Affects Versions: 4.4.CR1 > Reporter: Gytis Trikleris > Assignee: Paul Robinson > > WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. > Discussion currently happening here: https://community.jboss.org/message/831313 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1494) Produce performance figures to show performance improvements of Compensations over ACID In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1494: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > Produce performance figures to show performance improvements of Compensations over ACID > --------------------------------------------------------------------------------------- > > Key: JBTM-1494 > URL: https://issues.jboss.org/browse/JBTM-1494 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing, XTS > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Fix For: 6.0.0 > > > As part of evangelising compensations, it would be useful to show performance comparisons for different classes of applications. > Ideally, these results should show that that, for certain classes of applications, the performance of a compensation-based transaction is a lot better than for an ACID transaction. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:07 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2214) Remove deprecation warnings for com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2214: -------------------------------- Reporter: Gytis Trikleris (was: Tom Jenkinson) > Remove deprecation warnings for com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2214 > URL: https://issues.jboss.org/browse/JBTM-2214 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 5.0.2 > Reporter: Gytis Trikleris > Assignee: Paul Robinson > > If you run: > ./build.sh clean install -DskipTests | grep "com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated" > You will see: > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessAgreementWithParticipantCompletionStub.java:[173,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/SubordinateCoordinatorCompletionParticipantStub.java:[260,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessAgreementWithCoordinatorCompletionStub.java:[207,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestFaultedExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[64,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestNoExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[59,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestNoExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[62,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestFaultedExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[60,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wstx/tests/common/FailureBusinessParticipant.java:[106,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wstx/tests/common/DemoBusinessParticipant.java:[100,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestSystemExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[67,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestWrongStateExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[63,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestSystemExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[63,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestWrongStateExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[67,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/webservices/bainterop/participant/ParticipantCompletionParticipantAdapter.java:[56,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/xtstest/src/org/jboss/jbossts/xts/servicetests/service/participant/ParticipantCompletionTestParticipant.java:[99,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/compensations/impl/ParticipantImpl.java:[144,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/compensations/impl/remote/RemoteParticipant.java:[81,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[113,21] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[116,21] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:07 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1953) Check other byteman_support scripts support message replay In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1953: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > Check other byteman_support scripts support message replay > ---------------------------------------------------------- > > Key: JBTM-1953 > URL: https://issues.jboss.org/browse/JBTM-1953 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing, XTS > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Fix For: 6.0.0 > > > See comments towards end of here: JBTM-1919 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:07 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1688) TXBridge doesn't support "loops" or "diamonds" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1688: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > TXBridge doesn't support "loops" or "diamonds" > ---------------------------------------------- > > Key: JBTM-1688 > URL: https://issues.jboss.org/browse/JBTM-1688 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge, XTS > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Fix For: 6.0.0 > > > See here: http://docs.jboss.org/jbosstm/5.0.0.M2/guides/txbridge_guide/index.html#d0e590 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:55:08 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 10:55:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1679) Make @CompensationScoped beans available during recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1679: -------------------------------- Reporter: Gytis Trikleris (was: Paul Robinson) > Make @CompensationScoped beans available during recovery > -------------------------------------------------------- > > Key: JBTM-1679 > URL: https://issues.jboss.org/browse/JBTM-1679 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Gytis Trikleris > Assignee: Paul Robinson > Fix For: 6.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:08 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1859) Remove classname Strings from XTS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1859: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Remove classname Strings from XTS subsystem > ------------------------------------------- > > Key: JBTM-1859 > URL: https://issues.jboss.org/browse/JBTM-1859 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe. > When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details. > However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName(). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1679) Make @CompensationScoped beans available during recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1679: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Make @CompensationScoped beans available during recovery > -------------------------------------------------------- > > Key: JBTM-1679 > URL: https://issues.jboss.org/browse/JBTM-1679 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:07 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-846) Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-846: ------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-846 > URL: https://issues.jboss.org/browse/JBTM-846 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA, JTS, Recovery, Transaction Core, XTS > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > ** This Jira is a work in progress - I (Paul) will update the details here once the requirements in https://community.jboss.org/message/828391 are clarified. ** > The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container. > This will require removal of much of the static configuration state such as StateManager references to ObjectStore -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1688) TXBridge doesn't support "loops" or "diamonds" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1688: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > TXBridge doesn't support "loops" or "diamonds" > ---------------------------------------------- > > Key: JBTM-1688 > URL: https://issues.jboss.org/browse/JBTM-1688 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > See here: http://docs.jboss.org/jbosstm/5.0.0.M2/guides/txbridge_guide/index.html#d0e590 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-396) Provide one-phase commit optimization for WS-TX In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-396: ------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Provide one-phase commit optimization for WS-TX > ----------------------------------------------- > > Key: JBTM-396 > URL: https://issues.jboss.org/browse/JBTM-396 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Affects Versions: 4.4.CR1 > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. > Discussion currently happening here: https://community.jboss.org/message/831313 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1680) Allow 2PC participants to enlist in a compensation-based transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1680: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Allow 2PC participants to enlist in a compensation-based transaction > -------------------------------------------------------------------- > > Key: JBTM-1680 > URL: https://issues.jboss.org/browse/JBTM-1680 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > In some situations a developer may need to coordinate multiple resources, where some are 2PC and some are not. Here it could be possible to use enlist the 2PC participants in a compensation-based transaction. The xa.prepare happens in the complete phase, the xa.commit during close and xa.rollback during compensate. > This could provide an alternative to LRCO, where the last resource is compensation-based and the other resources remain 2PC. The benefit of this approach is that the failure window associated with LRCO does not exist. The negative of this approach is that the isolation of the compensation-based participant is reduced. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:07 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2213) Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2213: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba > ------------------------------------------------------------------------------------------ > > Key: JBTM-2213 > URL: https://issues.jboss.org/browse/JBTM-2213 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Affects Versions: 5.0.2 > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > If you run: > ./build.sh clean install -DskipTests | grep "org.jboss.narayana.txframework.api.annotation.lifecycle.ba" > You will see: > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipant.java:[45,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[112,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[154,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[115,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[162,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[57,146] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[115,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[158,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[62,27] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[65,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[118,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[166,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1468) Support pure-JTA client and server for WS-AT and REST-AT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1468: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Support pure-JTA client and server for WS-AT and REST-AT > -------------------------------------------------------- > > Key: JBTM-1468 > URL: https://issues.jboss.org/browse/JBTM-1468 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: REST, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > This allows the Client and server application to just use the JTA APIs, whilst having the distribution done over WS-AT or REST-AT. > To do this we need to: > # Remove @Transactional annotation. We then need to use some other mechanism to support the (optional) WS-AT participants that want to use annotations. > # Client side JTA->REST-AT bridge. Needs implementing. > # Server side REST-AT->JTA bridge. Needs integrating into code base. > # Update the TXBridge quickstarts to use this and move them out. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1705) Remove CDIExtensionProcessor in the XTS subsytem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1705: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Remove CDIExtensionProcessor in the XTS subsytem > ------------------------------------------------ > > Key: JBTM-1705 > URL: https://issues.jboss.org/browse/JBTM-1705 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > WFLY-1370 removes the need for the CDIExtensionProcessor in the XTS subsytem. > There is currently a hack in CDIExtensionProcessor in 5_BRANCH. This MUST be removed if WFLY-1370 is not merged in time for release. Hence I have marked this as critical. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2214) Remove deprecation warnings for com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2214: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Remove deprecation warnings for com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2214 > URL: https://issues.jboss.org/browse/JBTM-2214 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 5.0.2 > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > If you run: > ./build.sh clean install -DskipTests | grep "com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated" > You will see: > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessAgreementWithParticipantCompletionStub.java:[173,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/SubordinateCoordinatorCompletionParticipantStub.java:[260,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessAgreementWithCoordinatorCompletionStub.java:[207,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestFaultedExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[64,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestNoExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[59,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestNoExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[62,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestFaultedExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[60,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wstx/tests/common/FailureBusinessParticipant.java:[106,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wstx/tests/common/DemoBusinessParticipant.java:[100,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestSystemExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[67,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestWrongStateExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[63,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestSystemExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[63,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestWrongStateExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[67,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/webservices/bainterop/participant/ParticipantCompletionParticipantAdapter.java:[56,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/xtstest/src/org/jboss/jbossts/xts/servicetests/service/participant/ParticipantCompletionTestParticipant.java:[99,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/compensations/impl/ParticipantImpl.java:[144,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/compensations/impl/remote/RemoteParticipant.java:[81,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[113,21] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[116,21] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1507) Review the TXBridge tests usage of Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1507: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Review the TXBridge tests usage of Arquillian > --------------------------------------------- > > Key: JBTM-1507 > URL: https://issues.jboss.org/browse/JBTM-1507 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Testing, TxBridge > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The TXBridge tests don;t seem to be using Arquillian correctly. There is a servlet that is invoked to do things inside the container. As the tests (should) now run in the container, this should not be needed. > The tests also seem to have added complexity due to the recovery tests. As the recovery tests need to be able to kill the container, it mandates manual container lifecycle management for *all* tests. We may want to pull out the recovery tests into a separate module. > We also may want to pull out the DisabledContextPropagationTest into a separate module as they use a modified AS configuration. > We should also take a general look at how the tests are structured and using Arq. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1494) Produce performance figures to show performance improvements of Compensations over ACID In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1494: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Produce performance figures to show performance improvements of Compensations over ACID > --------------------------------------------------------------------------------------- > > Key: JBTM-1494 > URL: https://issues.jboss.org/browse/JBTM-1494 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > As part of evangelising compensations, it would be useful to show performance comparisons for different classes of applications. > Ideally, these results should show that that, for certain classes of applications, the performance of a compensation-based transaction is a lot better than for an ACID transaction. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1639) Improve XTS Api for looking up Recovery Manager to prevent developer from poling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1639: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Improve XTS Api for looking up Recovery Manager to prevent developer from poling > -------------------------------------------------------------------------------- > > Key: JBTM-1639 > URL: https://issues.jboss.org/browse/JBTM-1639 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > Currently the developer needs to poll for the RecoveryManager as it's possible that the application can be deployed before the XTS subsystem has finished startup. > This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the application poll until the RM was not null. > Two possible solutions: > Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return until there is an RM available. if we use the existing java method, we need to analyse all usages to make sure returning null is not a valid outcome. > Another solution is to find out how to delay the application's initialisation until after XTS has started. This puts the burden on the application developer to implement, but requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for initialising the application. I tried three and none of them fired after the server had booted. > To Reproduce > Put breakpoints on: > Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all threads > XTSATRecoveryManager.setRecoveryManager() // stop on Thread only > Copy your application to the deploy directory (xtstest.war is a good choice). Now start the server with debugging enabled (suspend=y). To reproduce this you will see the XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to continue and you will notice it is null. Fix this problem, and the getRecoveryManager will wait until the setRecoveryManager is complete and thus always return a non-null RM. > Once this is fixed, find all occurrence of the polling work-around and have them use the solution to this issue. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1715) NPE when using CompensationManager within an in-flowed WS-BA transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1715: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > NPE when using CompensationManager within an in-flowed WS-BA transaction > ------------------------------------------------------------------------ > > Key: JBTM-1715 > URL: https://issues.jboss.org/browse/JBTM-1715 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction. > {quote} > 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100] > ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS > HOT] > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:01:07 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:01:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1953) Check other byteman_support scripts support message replay In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1953: -------------------------------- Assignee: Gytis Trikleris (was: Paul Robinson) > Check other byteman_support scripts support message replay > ---------------------------------------------------------- > > Key: JBTM-1953 > URL: https://issues.jboss.org/browse/JBTM-1953 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > See comments towards end of here: JBTM-1919 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:03:02 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1953) Check other byteman_support scripts support message replay In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1953: -------------------------------- Reporter: Paul (was: Gytis Trikleris) > Check other byteman_support scripts support message replay > ---------------------------------------------------------- > > Key: JBTM-1953 > URL: https://issues.jboss.org/browse/JBTM-1953 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing, XTS > Reporter: Paul > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > See comments towards end of here: JBTM-1919 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:03:03 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1953) Check other byteman_support scripts support message replay In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1953: -------------------------------- Reporter: Paul Robinson (was: Paul) > Check other byteman_support scripts support message replay > ---------------------------------------------------------- > > Key: JBTM-1953 > URL: https://issues.jboss.org/browse/JBTM-1953 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > See comments towards end of here: JBTM-1919 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:04:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:04:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1688) TXBridge doesn't support "loops" or "diamonds" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1688: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > TXBridge doesn't support "loops" or "diamonds" > ---------------------------------------------- > > Key: JBTM-1688 > URL: https://issues.jboss.org/browse/JBTM-1688 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > See here: http://docs.jboss.org/jbosstm/5.0.0.M2/guides/txbridge_guide/index.html#d0e590 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:04:05 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:04:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1679) Make @CompensationScoped beans available during recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1679: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > Make @CompensationScoped beans available during recovery > -------------------------------------------------------- > > Key: JBTM-1679 > URL: https://issues.jboss.org/browse/JBTM-1679 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:04:06 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:04:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1494) Produce performance figures to show performance improvements of Compensations over ACID In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1494: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > Produce performance figures to show performance improvements of Compensations over ACID > --------------------------------------------------------------------------------------- > > Key: JBTM-1494 > URL: https://issues.jboss.org/browse/JBTM-1494 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > As part of evangelising compensations, it would be useful to show performance comparisons for different classes of applications. > Ideally, these results should show that that, for certain classes of applications, the performance of a compensation-based transaction is a lot better than for an ACID transaction. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:05:02 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:05:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2214) Remove deprecation warnings for com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2214: -------------------------------- Reporter: Tom Jenkinson (was: Gytis Trikleris) > Remove deprecation warnings for com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2214 > URL: https://issues.jboss.org/browse/JBTM-2214 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 5.0.2 > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > > If you run: > ./build.sh clean install -DskipTests | grep "com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated" > You will see: > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessAgreementWithParticipantCompletionStub.java:[173,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/SubordinateCoordinatorCompletionParticipantStub.java:[260,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessAgreementWithCoordinatorCompletionStub.java:[207,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestFaultedExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[64,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestNoExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[59,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestNoExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[62,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestFaultedExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[60,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wstx/tests/common/FailureBusinessParticipant.java:[106,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wstx/tests/common/DemoBusinessParticipant.java:[100,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestSystemExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[67,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestWrongStateExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[63,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestSystemExceptionBusinessAgreementWithParticipantCompletionParticipant.java:[63,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/unit/src/test/java/com/arjuna/wst/tests/common/TestWrongStateExceptionBusinessAgreementWithCoordinatorCompletionParticipant.java:[67,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/webservices/bainterop/participant/ParticipantCompletionParticipantAdapter.java:[56,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/XTS/localjunit/xtstest/src/org/jboss/jbossts/xts/servicetests/service/participant/ParticipantCompletionTestParticipant.java:[99,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/compensations/impl/ParticipantImpl.java:[144,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/compensations/impl/remote/RemoteParticipant.java:[81,17] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[113,21] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[116,21] unknown() in com.arjuna.wst.BusinessAgreementWithParticipantCompletionParticipant has been deprecated -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:05:02 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:05:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2213) Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2213: -------------------------------- Reporter: Tom Jenkinson (was: Gytis Trikleris) > Remove deprecation warnings for org.jboss.narayana.txframework.api.annotation.lifecycle.ba > ------------------------------------------------------------------------------------------ > > Key: JBTM-2213 > URL: https://issues.jboss.org/browse/JBTM-2213 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Affects Versions: 5.0.2 > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > > If you run: > ./build.sh clean install -DskipTests | grep "org.jboss.narayana.txframework.api.annotation.lifecycle.ba" > You will see: > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/main/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipant.java:[45,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[31,66] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[112,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[154,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[115,10] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[162,6] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[57,146] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBACoordinatorCompletionParticipantTest.java:[115,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/coordinatorCompletion/BACoordinatorCompletionService.java:[158,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[62,27] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[65,130] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/impl/handlers/wsba/WSBAParticipantCompletionParticipantTest.java:[118,32] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated > [WARNING] /home/tom/projects/jbosstm/narayana/txframework/src/test/java/org/jboss/narayana/txframework/functional/ws/ba/participantCompletion/BAParticipantCompletionService.java:[166,18] org.jboss.narayana.txframework.api.annotation.lifecycle.ba.Unknown in org.jboss.narayana.txframework.api.annotation.lifecycle.ba has been deprecated -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:06:03 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:06:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-396) Provide one-phase commit optimization for WS-TX In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-396: ------------------------------- Reporter: Mark Little (was: Gytis Trikleris) > Provide one-phase commit optimization for WS-TX > ----------------------------------------------- > > Key: JBTM-396 > URL: https://issues.jboss.org/browse/JBTM-396 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Affects Versions: 4.4.CR1 > Reporter: Mark Little > Assignee: Gytis Trikleris > > WS-AT does not support 1PC optimization. WS-ACID from WS-CAF does. It would be good to provide a configurable option for WS-AT users to enable 1PC optimization. This obviously breaks interoperability, which is why the default should be to have it disabled. > Discussion currently happening here: https://community.jboss.org/message/831313 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:06:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:06:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1859) Remove classname Strings from XTS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1859: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > Remove classname Strings from XTS subsystem > ------------------------------------------- > > Key: JBTM-1859 > URL: https://issues.jboss.org/browse/JBTM-1859 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe. > When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details. > However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName(). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:06:04 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:06:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1680) Allow 2PC participants to enlist in a compensation-based transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1680: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > Allow 2PC participants to enlist in a compensation-based transaction > -------------------------------------------------------------------- > > Key: JBTM-1680 > URL: https://issues.jboss.org/browse/JBTM-1680 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > In some situations a developer may need to coordinate multiple resources, where some are 2PC and some are not. Here it could be possible to use enlist the 2PC participants in a compensation-based transaction. The xa.prepare happens in the complete phase, the xa.commit during close and xa.rollback during compensate. > This could provide an alternative to LRCO, where the last resource is compensation-based and the other resources remain 2PC. The benefit of this approach is that the failure window associated with LRCO does not exist. The negative of this approach is that the isolation of the compensation-based participant is reduced. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:07:03 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:07:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1639) Improve XTS Api for looking up Recovery Manager to prevent developer from poling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1639: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > Improve XTS Api for looking up Recovery Manager to prevent developer from poling > -------------------------------------------------------------------------------- > > Key: JBTM-1639 > URL: https://issues.jboss.org/browse/JBTM-1639 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > Currently the developer needs to poll for the RecoveryManager as it's possible that the application can be deployed before the XTS subsystem has finished startup. > This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the application poll until the RM was not null. > Two possible solutions: > Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return until there is an RM available. if we use the existing java method, we need to analyse all usages to make sure returning null is not a valid outcome. > Another solution is to find out how to delay the application's initialisation until after XTS has started. This puts the burden on the application developer to implement, but requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for initialising the application. I tried three and none of them fired after the server had booted. > To Reproduce > Put breakpoints on: > Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all threads > XTSATRecoveryManager.setRecoveryManager() // stop on Thread only > Copy your application to the deploy directory (xtstest.war is a good choice). Now start the server with debugging enabled (suspend=y). To reproduce this you will see the XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to continue and you will notice it is null. Fix this problem, and the getRecoveryManager will wait until the setRecoveryManager is complete and thus always return a non-null RM. > Once this is fixed, find all occurrence of the polling work-around and have them use the solution to this issue. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:07:03 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:07:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1715) NPE when using CompensationManager within an in-flowed WS-BA transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1715: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > NPE when using CompensationManager within an in-flowed WS-BA transaction > ------------------------------------------------------------------------ > > Key: JBTM-1715 > URL: https://issues.jboss.org/browse/JBTM-1715 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction. > {quote} > 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100] > ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS > HOT] > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:07:03 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Fri, 19 Sep 2014 11:07:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1507) Review the TXBridge tests usage of Arquillian In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1507: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > Review the TXBridge tests usage of Arquillian > --------------------------------------------- > > Key: JBTM-1507 > URL: https://issues.jboss.org/browse/JBTM-1507 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Testing, TxBridge > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 6.0.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The TXBridge tests don;t seem to be using Arquillian correctly. There is a servlet that is invoked to do things inside the container. As the tests (should) now run in the container, this should not be needed. > The tests also seem to have added complexity due to the recovery tests. As the recovery tests need to be able to kill the container, it mandates manual container lifecycle management for *all* tests. We may want to pull out the recovery tests into a separate module. > We also may want to pull out the DisabledContextPropagationTest into a separate module as they use a modified AS configuration. > We should also take a general look at how the tests are structured and using Arq. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:59:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 19 Sep 2014 11:59:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004375#comment-13004375 ] Mark Little commented on JBTM-2256: ----------------------------------- OK. I'm more interested in ensuring we have some (semi)automated test to verify the fix and that nothing like this creeps in again. How that is done is not that important. > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 06:06:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 22 Sep 2014 06:06:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004626#comment-13004626 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1143947|https://bugzilla.redhat.com/show_bug.cgi?id=1143947] from NEW to ASSIGNED > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:36:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Sep 2014 07:36:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2258) Update the build process to build a binary distribution of Narayana during normal install phase In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2258: ----------------------------------- Summary: Update the build process to build a binary distribution of Narayana during normal install phase Key: JBTM-2258 URL: https://issues.jboss.org/browse/JBTM-2258 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.4 Do not include the Javadocs as these are all available online and this is consistent with not including the docs any more too. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:38:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Sep 2014 07:38:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2258) Update the build process to build a binary distribution of Narayana during normal install phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2258: -------------------------------- Description: ./build.sh install (or just ./build.sh - install is the default) should build the release zip. We have removed the JavaDocs from the dist as these are available online (including previous versions) and this is consistent with not including the docs either. was:Do not include the Javadocs as these are all available online and this is consistent with not including the docs any more too. > Update the build process to build a binary distribution of Narayana during normal install phase > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2258 > URL: https://issues.jboss.org/browse/JBTM-2258 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > ./build.sh install (or just ./build.sh - install is the default) should build the release zip. > We have removed the JavaDocs from the dist as these are available online (including previous versions) and this is consistent with not including the docs either. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 07:39:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Sep 2014 07:39:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2258) Update the build process to build a binary distribution of Narayana during normal install phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2258: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/733 > Update the build process to build a binary distribution of Narayana during normal install phase > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2258 > URL: https://issues.jboss.org/browse/JBTM-2258 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > ./build.sh install (or just ./build.sh - install is the default) should build the release zip. > We have removed the JavaDocs from the dist as these are available online (including previous versions) and this is consistent with not including the docs either. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 04:52:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 23 Sep 2014 04:52:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2241: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1143947, https://bugzilla.redhat.com/show_bug.cgi?id=1143956, https://bugzilla.redhat.com/show_bug.cgi?id=1145513 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1143947, https://bugzilla.redhat.com/show_bug.cgi?id=1143956) > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 05:24:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 23 Sep 2014 05:24:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2242: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1133346, https://bugzilla.redhat.com/show_bug.cgi?id=1143956 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1133346) > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 05:39:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 23 Sep 2014 05:39:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005197#comment-13005197 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- Ivo Studensky changed the Status of [bug 1145513|https://bugzilla.redhat.com/show_bug.cgi?id=1145513] from NEW to CLOSED > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 19:00:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Sep 2014 19:00:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2259: -------------------------------------- Summary: Allow the ordering of some synchronizations to be configurable Key: JBTM-2259 URL: https://issues.jboss.org/browse/JBTM-2259 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTA Affects Versions: 5.0.3 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.0.4 IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA). The request is to add a configuration option to control the order in which certain synchronizations are called. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 19:13:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Sep 2014 19:13:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2259: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/734 > Allow the ordering of some synchronizations to be configurable > --------------------------------------------------------------- > > Key: JBTM-2259 > URL: https://issues.jboss.org/browse/JBTM-2259 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA). > The request is to add a configuration option to control the order in which certain synchronizations are called. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 09:20:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Sep 2014 09:20:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2216) Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2216: -------------------------------- Fix Version/s: 4.17.23 > Extraneous warning message observed in XARecoveryModule.xaRecoverySecondPass if the first pass has already failed > ----------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2216 > URL: https://issues.jboss.org/browse/JBTM-2216 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.17.20, 4.17.21, 5.0.2 > Environment: JBoss EAP 6.3 > Reporter: Tom Ross > Assignee: Tom Jenkinson > Fix For: 4.17.23, 5.0.4 > > > When using AMQ failover protocol, the Narayana recovery process generates the following exception: > {noformat} > 10:19:36,053 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true > 10:21:46,139 INFO [org.apache.activemq.transport.failover.FailoverTransport] (ActiveMQ Task-1) Successfully connected to tcp://ragga:61616?trace=true > 10:21:46,139 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Failover transport not connected: unconnected > at org.apache.activemq.TransactionContext.recover(TransactionContext.java:656) > at org.apache.activemq.ra.LocalAndXATransaction.recover(LocalAndXATransaction.java:135) > at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.recover(XAResourceWrapperImpl.java:177) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:548) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:187) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > 10:21:56,165 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:619) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-jacorb-4.17.21.Final-redhat-1.jar:4.17.21.Final-redhat-1] > {noformat} > Although the first message may be expected if the resource manager throws an exception in XAResource::recover(), the second message does not add any further assistance in resolving the issue and should be removed as noise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 09:39:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 24 Sep 2014 09:39:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005715#comment-13005715 ] Mark Little commented on JBTM-2259: ----------------------------------- One of the reasons we haven't done this to date is that it's not standards compliant. Why isn't the ordering that JTA allowed in the interposed option sufficient? > Allow the ordering of some synchronizations to be configurable > --------------------------------------------------------------- > > Key: JBTM-2259 > URL: https://issues.jboss.org/browse/JBTM-2259 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA). > The request is to add a configuration option to control the order in which certain synchronizations are called. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 09:54:03 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 24 Sep 2014 09:54:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/732, https://github.com/jbosstm/narayana/pull/735 (was: https://github.com/jbosstm/narayana/pull/732) > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 09:54:03 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 24 Sep 2014 09:54:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Fix Version/s: 5.0.4 > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 09:55:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Sep 2014 09:55:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005727#comment-13005727 ] Tom Jenkinson commented on JBTM-2259: ------------------------------------- The case that is discussed on the forum is where two synchronizations both registered as interposed need to have ordering imposed between them. The two Synchronizations are from IronJacamar and a JPA persistence provider. When the JCA one runs, it closes the underlying connection and so if it happens to have been registered first it will close the connection before JPA flushes. > Allow the ordering of some synchronizations to be configurable > --------------------------------------------------------------- > > Key: JBTM-2259 > URL: https://issues.jboss.org/browse/JBTM-2259 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA). > The request is to add a configuration option to control the order in which certain synchronizations are called. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 10:27:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Sep 2014 10:27:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2260: ----------------------------------- Summary: BlackTie does not build on CentOS 7 Key: JBTM-2260 URL: https://issues.jboss.org/browse/JBTM-2260 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Tom Jenkinson Assignee: Amos Feng Fix For: 5.0.4 [hudson at sansa ~]$ uname -a Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console {quote} test-compile: [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes [cc] 11 total files to be compiled. [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION="); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION=linux"); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION="); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] [cc] int ret = waiter->svc(); [cc] ^ [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] [cc] int argc = 0; [cc] ^ [cc] Starting link [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' [cc] collect2: error: ld returned 1 exit status {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 11:43:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 24 Sep 2014 11:43:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005779#comment-13005779 ] Mark Little commented on JBTM-2259: ----------------------------------- OK, but this is not compliant with the standards and therefore if some other transaction engine is used it will break. The reason ordering of resources and synchronisations isn't supported in the standards is because it becomes very hard to manage global ordering in a heterogenous environment. Are we really happy to add something which basically ties IronJacamar and Narayana together? I'm no so sure. While it's nice to add something like resource ordering, as we do with AbstractRecords, it should be done cautiously, in situations where no other option is possible, or as an optimisation, i.e., so without it the system still works, but may be slower, less efficient etc. > Allow the ordering of some synchronizations to be configurable > --------------------------------------------------------------- > > Key: JBTM-2259 > URL: https://issues.jboss.org/browse/JBTM-2259 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA). > The request is to add a configuration option to control the order in which certain synchronizations are called. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 12:49:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 24 Sep 2014 12:49:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2261) start services scripts missing execute flag In-Reply-To: References: Message-ID: Mark Little created JBTM-2261: --------------------------------- Summary: start services scripts missing execute flag Key: JBTM-2261 URL: https://issues.jboss.org/browse/JBTM-2261 Project: JBoss Transaction Manager Issue Type: Task Components: JTS Affects Versions: 5.0.3 Reporter: Mark Little Assignee: Tom Jenkinson Priority: Minor Unix start transaction manager and recovery service scripts in bin directory are missing the execute bit. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 13:03:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 24 Sep 2014 13:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: Mark Little created JBTM-2262: --------------------------------- Summary: ORB JTS classes not added to classpath in setup script Key: JBTM-2262 URL: https://issues.jboss.org/browse/JBTM-2262 Project: JBoss Transaction Manager Issue Type: Task Components: JTS Affects Versions: 5.0.3 Reporter: Mark Little Assignee: Tom Jenkinson Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 02:53:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 02:53:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005925#comment-13005925 ] Tom Jenkinson commented on JBTM-2262: ------------------------------------- Hi Mark, There is probably a change required in this area but the readme.txt does contain the information to configure the JTS installation for JacORB: {quote} 1. Execute jts-setup-env.[bat|sh] to put Narayana in the classpath 2. export CLASSPATH=$CLASSPATH:$NARAYANA_HOME/lib/jts/narayana-jts-jacorb.jar {quote} Unfortunately though, the readme doesn't contain the information of what to do if you are wanting to use JDK orb. There are a couple of options therefore: 1. Provide two scripts - one for Jacorb one for IDLj - probably my preference 2. Update the readme to have two versions of step 2 above 3. Update the current jts-setup-env.[bat|sh] to include JacORB and provide instructions on how to amend it to install IDLj Let me know your preference, Tom > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 03:29:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 03:29:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2261) start services scripts missing execute flag In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2261. --------------------------------- Fix Version/s: 5.0.4 Resolution: Done Merged in https://github.com/jbosstm/narayana/commit/eb6234a72c03d0fde2425616384f6a8d9ef235cb which fixes the flags. I checked and there should be no more .sh in the dist without that flag. > start services scripts missing execute flag > ------------------------------------------- > > Key: JBTM-2261 > URL: https://issues.jboss.org/browse/JBTM-2261 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.0.4 > > > Unix start transaction manager and recovery service scripts in bin directory are missing the execute bit. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 03:34:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 03:34:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2263) Schema validation error for RTS webservice web.xml In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2263: ----------------------------------- Summary: Schema validation error for RTS webservice web.xml Key: JBTM-2263 URL: https://issues.jboss.org/browse/JBTM-2263 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Reporter: Tom Jenkinson Assignee: Michael Musgrove Fix For: 4.17.23, 5.0.4 When I cleaned the IDE I noticed some schema validation errors on the file: rts/at/webservice/src/main/webapp/WEB-INF/web.xml Generally summarised as: {quote} cvc-complex-type.2.4.a: Invalid content was found starting with element 'display-name'. One of '{"http://java.sun.com/xml/ns/javaee":module-name, "http://java.sun.com/xml/ns/javaee":distributable, "http://java.sun.com/xml/ns/javaee":context-param, "http://java.sun.com/xml/ns/javaee":filter, "http://java.sun.com/xml/ns/javaee":filter-mapping, "http://java.sun.com/xml/ns/javaee":listener, "http://java.sun.com/xml/ns/javaee":servlet, "http://java.sun.com/xml/ns/javaee":servlet-mapping, "http://java.sun.com/xml/ns/javaee":session-config, "http://java.sun.com/xml/ns/javaee":mime-mapping, "http://java.sun.com/xml/ns/javaee":welcome-file-list, "http://java.sun.com/xml/ns/javaee":error-page, "http://java.sun.com/xml/ns/javaee":jsp-config, "http://java.sun.com/xml/ns/javaee":security-constraint, "http://java.sun.com/xml/ns/javaee":login-config, "http://java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":message-destination, "http://java.sun.com/xml/ns/javaee":locale-encoding-mapping-list, "http://java.sun.com/xml/ns/javaee":absolute-ordering}' is expected. {quote} I have a PR that would be good for you to take a quick look at... -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 03:36:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 03:36:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2263) Schema validation error for RTS webservice web.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2263: ----------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > Schema validation error for RTS webservice web.xml > -------------------------------------------------- > > Key: JBTM-2263 > URL: https://issues.jboss.org/browse/JBTM-2263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.23, 5.0.4 > > > When I cleaned the IDE I noticed some schema validation errors on the file: > rts/at/webservice/src/main/webapp/WEB-INF/web.xml > Generally summarised as: > {quote} > cvc-complex-type.2.4.a: Invalid content was found starting with element 'display-name'. One of '{"http://java.sun.com/xml/ns/javaee":module-name, "http://java.sun.com/xml/ns/javaee":distributable, "http://java.sun.com/xml/ns/javaee":context-param, "http://java.sun.com/xml/ns/javaee":filter, "http://java.sun.com/xml/ns/javaee":filter-mapping, "http://java.sun.com/xml/ns/javaee":listener, "http://java.sun.com/xml/ns/javaee":servlet, "http://java.sun.com/xml/ns/javaee":servlet-mapping, "http://java.sun.com/xml/ns/javaee":session-config, "http://java.sun.com/xml/ns/javaee":mime-mapping, "http://java.sun.com/xml/ns/javaee":welcome-file-list, "http://java.sun.com/xml/ns/javaee":error-page, "http://java.sun.com/xml/ns/javaee":jsp-config, "http://java.sun.com/xml/ns/javaee":security-constraint, "http://java.sun.com/xml/ns/javaee":login-config, "http://java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":message-destination, "http://java.sun.com/xml/ns/javaee":locale-encoding-mapping-list, "http://java.sun.com/xml/ns/javaee":absolute-ordering}' is expected. > {quote} > I have a PR that would be good for you to take a quick look at... -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 03:36:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 03:36:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2263) Schema validation error for RTS webservice web.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2263: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/736 > Schema validation error for RTS webservice web.xml > -------------------------------------------------- > > Key: JBTM-2263 > URL: https://issues.jboss.org/browse/JBTM-2263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.23, 5.0.4 > > > When I cleaned the IDE I noticed some schema validation errors on the file: > rts/at/webservice/src/main/webapp/WEB-INF/web.xml > Generally summarised as: > {quote} > cvc-complex-type.2.4.a: Invalid content was found starting with element 'display-name'. One of '{"http://java.sun.com/xml/ns/javaee":module-name, "http://java.sun.com/xml/ns/javaee":distributable, "http://java.sun.com/xml/ns/javaee":context-param, "http://java.sun.com/xml/ns/javaee":filter, "http://java.sun.com/xml/ns/javaee":filter-mapping, "http://java.sun.com/xml/ns/javaee":listener, "http://java.sun.com/xml/ns/javaee":servlet, "http://java.sun.com/xml/ns/javaee":servlet-mapping, "http://java.sun.com/xml/ns/javaee":session-config, "http://java.sun.com/xml/ns/javaee":mime-mapping, "http://java.sun.com/xml/ns/javaee":welcome-file-list, "http://java.sun.com/xml/ns/javaee":error-page, "http://java.sun.com/xml/ns/javaee":jsp-config, "http://java.sun.com/xml/ns/javaee":security-constraint, "http://java.sun.com/xml/ns/javaee":login-config, "http://java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":message-destination, "http://java.sun.com/xml/ns/javaee":locale-encoding-mapping-list, "http://java.sun.com/xml/ns/javaee":absolute-ordering}' is expected. > {quote} > I have a PR that would be good for you to take a quick look at... -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 03:36:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 03:36:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2263) Schema validation error for RTS webservice web.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2263: -------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Schema validation error for RTS webservice web.xml > -------------------------------------------------- > > Key: JBTM-2263 > URL: https://issues.jboss.org/browse/JBTM-2263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > When I cleaned the IDE I noticed some schema validation errors on the file: > rts/at/webservice/src/main/webapp/WEB-INF/web.xml > Generally summarised as: > {quote} > cvc-complex-type.2.4.a: Invalid content was found starting with element 'display-name'. One of '{"http://java.sun.com/xml/ns/javaee":module-name, "http://java.sun.com/xml/ns/javaee":distributable, "http://java.sun.com/xml/ns/javaee":context-param, "http://java.sun.com/xml/ns/javaee":filter, "http://java.sun.com/xml/ns/javaee":filter-mapping, "http://java.sun.com/xml/ns/javaee":listener, "http://java.sun.com/xml/ns/javaee":servlet, "http://java.sun.com/xml/ns/javaee":servlet-mapping, "http://java.sun.com/xml/ns/javaee":session-config, "http://java.sun.com/xml/ns/javaee":mime-mapping, "http://java.sun.com/xml/ns/javaee":welcome-file-list, "http://java.sun.com/xml/ns/javaee":error-page, "http://java.sun.com/xml/ns/javaee":jsp-config, "http://java.sun.com/xml/ns/javaee":security-constraint, "http://java.sun.com/xml/ns/javaee":login-config, "http://java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":message-destination, "http://java.sun.com/xml/ns/javaee":locale-encoding-mapping-list, "http://java.sun.com/xml/ns/javaee":absolute-ordering}' is expected. > {quote} > I have a PR that would be good for you to take a quick look at... -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 03:58:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Sep 2014 03:58:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2263) Schema validation error for RTS webservice web.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005944#comment-13005944 ] Michael Musgrove commented on JBTM-2263: ---------------------------------------- The change looks good, well spotted. > Schema validation error for RTS webservice web.xml > -------------------------------------------------- > > Key: JBTM-2263 > URL: https://issues.jboss.org/browse/JBTM-2263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > When I cleaned the IDE I noticed some schema validation errors on the file: > rts/at/webservice/src/main/webapp/WEB-INF/web.xml > Generally summarised as: > {quote} > cvc-complex-type.2.4.a: Invalid content was found starting with element 'display-name'. One of '{"http://java.sun.com/xml/ns/javaee":module-name, "http://java.sun.com/xml/ns/javaee":distributable, "http://java.sun.com/xml/ns/javaee":context-param, "http://java.sun.com/xml/ns/javaee":filter, "http://java.sun.com/xml/ns/javaee":filter-mapping, "http://java.sun.com/xml/ns/javaee":listener, "http://java.sun.com/xml/ns/javaee":servlet, "http://java.sun.com/xml/ns/javaee":servlet-mapping, "http://java.sun.com/xml/ns/javaee":session-config, "http://java.sun.com/xml/ns/javaee":mime-mapping, "http://java.sun.com/xml/ns/javaee":welcome-file-list, "http://java.sun.com/xml/ns/javaee":error-page, "http://java.sun.com/xml/ns/javaee":jsp-config, "http://java.sun.com/xml/ns/javaee":security-constraint, "http://java.sun.com/xml/ns/javaee":login-config, "http://java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":message-destination, "http://java.sun.com/xml/ns/javaee":locale-encoding-mapping-list, "http://java.sun.com/xml/ns/javaee":absolute-ordering}' is expected. > {quote} > I have a PR that would be good for you to take a quick look at... -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 04:59:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 04:59:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2263) Schema validation error for RTS webservice web.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2263: ----------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > Schema validation error for RTS webservice web.xml > -------------------------------------------------- > > Key: JBTM-2263 > URL: https://issues.jboss.org/browse/JBTM-2263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.23, 5.0.4 > > > When I cleaned the IDE I noticed some schema validation errors on the file: > rts/at/webservice/src/main/webapp/WEB-INF/web.xml > Generally summarised as: > {quote} > cvc-complex-type.2.4.a: Invalid content was found starting with element 'display-name'. One of '{"http://java.sun.com/xml/ns/javaee":module-name, "http://java.sun.com/xml/ns/javaee":distributable, "http://java.sun.com/xml/ns/javaee":context-param, "http://java.sun.com/xml/ns/javaee":filter, "http://java.sun.com/xml/ns/javaee":filter-mapping, "http://java.sun.com/xml/ns/javaee":listener, "http://java.sun.com/xml/ns/javaee":servlet, "http://java.sun.com/xml/ns/javaee":servlet-mapping, "http://java.sun.com/xml/ns/javaee":session-config, "http://java.sun.com/xml/ns/javaee":mime-mapping, "http://java.sun.com/xml/ns/javaee":welcome-file-list, "http://java.sun.com/xml/ns/javaee":error-page, "http://java.sun.com/xml/ns/javaee":jsp-config, "http://java.sun.com/xml/ns/javaee":security-constraint, "http://java.sun.com/xml/ns/javaee":login-config, "http://java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":message-destination, "http://java.sun.com/xml/ns/javaee":locale-encoding-mapping-list, "http://java.sun.com/xml/ns/javaee":absolute-ordering}' is expected. > {quote} > I have a PR that would be good for you to take a quick look at... -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 04:59:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 04:59:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2263) Schema validation error for RTS webservice web.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2263: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Thanks Mike, I merged it. > Schema validation error for RTS webservice web.xml > -------------------------------------------------- > > Key: JBTM-2263 > URL: https://issues.jboss.org/browse/JBTM-2263 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.23, 5.0.4 > > > When I cleaned the IDE I noticed some schema validation errors on the file: > rts/at/webservice/src/main/webapp/WEB-INF/web.xml > Generally summarised as: > {quote} > cvc-complex-type.2.4.a: Invalid content was found starting with element 'display-name'. One of '{"http://java.sun.com/xml/ns/javaee":module-name, "http://java.sun.com/xml/ns/javaee":distributable, "http://java.sun.com/xml/ns/javaee":context-param, "http://java.sun.com/xml/ns/javaee":filter, "http://java.sun.com/xml/ns/javaee":filter-mapping, "http://java.sun.com/xml/ns/javaee":listener, "http://java.sun.com/xml/ns/javaee":servlet, "http://java.sun.com/xml/ns/javaee":servlet-mapping, "http://java.sun.com/xml/ns/javaee":session-config, "http://java.sun.com/xml/ns/javaee":mime-mapping, "http://java.sun.com/xml/ns/javaee":welcome-file-list, "http://java.sun.com/xml/ns/javaee":error-page, "http://java.sun.com/xml/ns/javaee":jsp-config, "http://java.sun.com/xml/ns/javaee":security-constraint, "http://java.sun.com/xml/ns/javaee":login-config, "http://java.sun.com/xml/ns/javaee":security-role, "http://java.sun.com/xml/ns/javaee":message-destination, "http://java.sun.com/xml/ns/javaee":locale-encoding-mapping-list, "http://java.sun.com/xml/ns/javaee":absolute-ordering}' is expected. > {quote} > I have a PR that would be good for you to take a quick look at... -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 07:03:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 25 Sep 2014 07:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006018#comment-13006018 ] Mark Little commented on JBTM-2262: ----------------------------------- I have no preference other than if we have a script called "setup" then it should setup ;) > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 07:04:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 07:04:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006020#comment-13006020 ] Tom Jenkinson commented on JBTM-2262: ------------------------------------- I will go with two scripts then, I think that is clearest. > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 08:08:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 25 Sep 2014 08:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006052#comment-13006052 ] Mark Little commented on JBTM-2262: ----------------------------------- BTW what did these scripts do in the old days? Did they add the jacorb jar explicitly? > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 08:12:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 08:12:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006054#comment-13006054 ] Tom Jenkinson commented on JBTM-2262: ------------------------------------- Yes they always assumed JacORB, this script was modified during our move to ensure JDK orb was suitably high profile. > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 08:48:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 08:48:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006088#comment-13006088 ] Tom Jenkinson commented on JBTM-2262: ------------------------------------- OK, I have committed a fix for this one https://github.com/jbosstm/narayana/commit/c8be49e2a7bb06356ae4450e0e59bae46661f46f > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 08:48:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Sep 2014 08:48:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2262. --------------------------------- Resolution: Done > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 09:18:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Thu, 25 Sep 2014 09:18:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006113#comment-13006113 ] Mark Little commented on JBTM-2262: ----------------------------------- OK, so we broke the public API by removing the ORB jar from the setup. Glad to see that fix :) > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 05:05:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 05:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2229) Issue with issue recovering AA with CMR, recovers OK but via orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006382#comment-13006382 ] RH Bugzilla Integration commented on JBTM-2229: ----------------------------------------------- Hayk Hovsepyan changed the Status of [bug 1124861|https://bugzilla.redhat.com/show_bug.cgi?id=1124861] from ON_QA to VERIFIED > Issue with issue recovering AA with CMR, recovers OK but via orphan detection > ----------------------------------------------------------------------------- > > Key: JBTM-2229 > URL: https://issues.jboss.org/browse/JBTM-2229 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.21, 5.0.2 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.22, 5.0.3 > > > The issue is with the CMR recovery module when it needs to update the underlying AA to modify it with the correct value from the CMR XIDS table. > If this AA does not have Serializable XARs, it will lead to the Xid being removed from XARM during getNewXAResource (via restore_state of the XARR). When the later AARM tries to recover the AA, it means a corresponding XAR for the XID cannot be located in the XARM by the XARR and an error message is reported. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:08:02 2014 From: issues at jboss.org ($eVeR sever (JIRA)) Date: Fri, 26 Sep 2014 06:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: $eVeR sever created JBTM-2264: --------------------------------- Summary: Error enlisting second xa resource on the same oracle instance but other schema Key: JBTM-2264 URL: https://issues.jboss.org/browse/JBTM-2264 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.0.3 Reporter: $eVeR sever Assignee: Tom Jenkinson I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. Whole stack trace: {noformat} oracle.jdbc.xa.OracleXAException at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) at SimpleJdbcTest.main(SimpleJdbcTest.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) at SimpleJdbcTest.main(SimpleJdbcTest.java:36) {noformat} (Detail log and SSCCE are attached). I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:12:02 2014 From: issues at jboss.org ($eVeR sever (JIRA)) Date: Fri, 26 Sep 2014 06:12:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] $eVeR sever updated JBTM-2264: ------------------------------ Attachment: test.log > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: $eVeR sever > Assignee: Tom Jenkinson > Attachments: test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:16:02 2014 From: issues at jboss.org ($eVeR sever (JIRA)) Date: Fri, 26 Sep 2014 06:16:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] $eVeR sever updated JBTM-2264: ------------------------------ Attachment: sscce.zip > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: $eVeR sever > Assignee: Tom Jenkinson > Attachments: sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:27:03 2014 From: issues at jboss.org (Evgeniy Smelik (JIRA)) Date: Fri, 26 Sep 2014 06:27:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Smelik updated JBTM-2264: --------------------------------- Attachment: sscce.zip > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 11:51:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 11:51:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006564#comment-13006564 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from NEW to POST > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 11:51:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 11:51:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006565#comment-13006565 ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from NEW to POST > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 15:46:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Sep 2014 15:46:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006627#comment-13006627 ] Tom Jenkinson commented on JBTM-2264: ------------------------------------- Hi Evgeniy, This issue comes about due to different handling of detecting duplicate XAResources when enlistResource is called on a transaction. With Bitronix (and possibly Atomikos) when an XAR is enlisted pointer comparison is used to detect whether or not an equivalent XAR is registered. With Narayana we use isSameRM to detect if the XAR are equivalent, even if they have different references. With BTM, it means that two different Xid are enlisted for the same resource manager, with Narayana it should have allowed us to use a single Xid for the two connections. In concrete terms your test leads to Narayana issuing the following calls: {quote} xaResource1.start(xid1, TMNOFLAGS) xaResource2.start(xid1, TMJOIN) {quote} Unfortunately with Oracle that results in an exception as you have found when the driver reports that the two XAresources are for the same resource manager. When Narayana is deployed in WildFly or EAP there is code in our JCA there to override the isSameRM method such that it will return false for Oracle and the two Xids would be created similar to BTM. I am still looking into this and will update you next week, Tom > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:04:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:04:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2238) Tooling does not expose CMR records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006634#comment-13006634 ] RH Bugzilla Integration commented on JBTM-2238: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1113225|https://bugzilla.redhat.com/show_bug.cgi?id=1113225] from ASSIGNED to MODIFIED > Tooling does not expose CMR records > ----------------------------------- > > Key: JBTM-2238 > URL: https://issues.jboss.org/browse/JBTM-2238 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > CMR resources are not being exposed as MBeans via the (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser) tooling. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:04:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:04:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006635#comment-13006635 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1143947|https://bugzilla.redhat.com/show_bug.cgi?id=1143947] from ASSIGNED to MODIFIED > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:04:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:04:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006636#comment-13006636 ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1133346|https://bugzilla.redhat.com/show_bug.cgi?id=1133346] from ASSIGNED to MODIFIED > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:04:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:04:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006637#comment-13006637 ] RH Bugzilla Integration commented on JBTM-2256: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1104584|https://bugzilla.redhat.com/show_bug.cgi?id=1104584] from NEW to MODIFIED > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:04:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:04:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006638#comment-13006638 ] RH Bugzilla Integration commented on JBTM-2255: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1080035|https://bugzilla.redhat.com/show_bug.cgi?id=1080035] from NEW to MODIFIED > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:04:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:04:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006639#comment-13006639 ] RH Bugzilla Integration commented on JBTM-1341: ----------------------------------------------- tom.jenkinson at redhat.com changed the Status of [bug 1139102|https://bugzilla.redhat.com/show_bug.cgi?id=1139102] from NEW to MODIFIED > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:39:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:39:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006644#comment-13006644 ] RH Bugzilla Integration commented on JBTM-1341: ----------------------------------------------- Kabir Khan changed the Status of [bug 1139102|https://bugzilla.redhat.com/show_bug.cgi?id=1139102] from MODIFIED to POST > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:39:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:39:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006645#comment-13006645 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- Kabir Khan changed the Status of [bug 1143947|https://bugzilla.redhat.com/show_bug.cgi?id=1143947] from MODIFIED to POST > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:39:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:39:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006647#comment-13006647 ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- Kabir Khan changed the Status of [bug 1133346|https://bugzilla.redhat.com/show_bug.cgi?id=1133346] from MODIFIED to POST > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:39:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:39:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2238) Tooling does not expose CMR records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006648#comment-13006648 ] RH Bugzilla Integration commented on JBTM-2238: ----------------------------------------------- Kabir Khan changed the Status of [bug 1113225|https://bugzilla.redhat.com/show_bug.cgi?id=1113225] from MODIFIED to POST > Tooling does not expose CMR records > ----------------------------------- > > Key: JBTM-2238 > URL: https://issues.jboss.org/browse/JBTM-2238 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > CMR resources are not being exposed as MBeans via the (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser) tooling. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:39:05 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:39:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006649#comment-13006649 ] RH Bugzilla Integration commented on JBTM-2256: ----------------------------------------------- Kabir Khan changed the Status of [bug 1104584|https://bugzilla.redhat.com/show_bug.cgi?id=1104584] from MODIFIED to POST > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 16:39:05 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 16:39:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006650#comment-13006650 ] RH Bugzilla Integration commented on JBTM-2255: ----------------------------------------------- Kabir Khan changed the Status of [bug 1080035|https://bugzilla.redhat.com/show_bug.cgi?id=1080035] from MODIFIED to POST > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 28 06:21:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Sun, 28 Sep 2014 06:21:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006699#comment-13006699 ] Mark Little commented on JBTM-2264: ----------------------------------- Just to add to what Tom has said, isSameRM is the required way of checking for RM equality. It's defined in the JTA specification. > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 28 16:12:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 28 Sep 2014 16:12:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2265) BlackTie CI test hang In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2265: -------------------------------------- Summary: BlackTie CI test hang Key: JBTM-2265 URL: https://issues.jboss.org/browse/JBTM-2265 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Affects Versions: 5.0.3 Reporter: Michael Musgrove Assignee: Amos Feng CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 28 19:44:02 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 28 Sep 2014 19:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2265) BlackTie CI test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2265. ---------------------------------- Resolution: Rejected I accidentally deleted the associated CI job. But the failure does look like a one off CI comms issue so rejecting (if it was a real issue then we will raise a new JIRA). > BlackTie CI test hang > --------------------- > > Key: JBTM-2265 > URL: https://issues.jboss.org/browse/JBTM-2265 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Amos Feng > > CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 05:43:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 29 Sep 2014 05:43:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2253) Brandon CI node misconfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reopened JBTM-2253: ----------------------------------- http://172.17.131.2/view/Status/job/narayana/653/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ http://172.17.131.2/view/Status/job/narayana/654/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ http://172.17.131.2/view/Status/job/narayana/655/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ http://172.17.131.2/view/Status/job/narayana/657/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ http://172.17.131.2/view/Status/job/narayana/658/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ http://172.17.131.2/view/Status/job/narayana/659/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6 > Brandon CI node misconfiguration > --------------------------------- > > Key: JBTM-2253 > URL: https://issues.jboss.org/browse/JBTM-2253 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/639/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ > {code} > 12:39:56,830 ERROR [org.codehaus.stomp.jms.ProtocolConverter] (StompConnect Transport: tcp:///127.0.0.1:44813) Connection is closed: org.codehaus.stomp.jms.ProtocolConverter at 10c10e8 > 12:39:56,831 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///127.0.0.1:44813) Caught an exception: Broken pipe: java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.write(SocketOutputStream.java:159) [rt.jar:1.7.0_51] > at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_51] > at java.io.FilterOutputStream.write(FilterOutputStream.java:97) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.marshal(StompMarshaller.java:83) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.onStompFrame(TcpTransport.java:80) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.sendToStomp(ProtocolConverter.java:498) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:209) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:101) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 110.88 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.TestTopic > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.162 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.server.BlackTieServerTestCase > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.248 sec > Results : > Tests in error: > AtmiBrokerEnvXMLTest.testEnv:53 ? UnknownHost brandon.buildnet.ncl.jboss.com: ... > TestConnection.setUp:29 ? Configuration Could not create the orb management fu... > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 05:53:02 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 29 Sep 2014 05:53:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2250) RecoveryManagerStartStopTest hang waiting for byteman rendezvous In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006813#comment-13006813 ] Gytis Trikleris commented on JBTM-2250: --------------------------------------- http://172.17.131.2/view/Status/job/narayana/PROFILE=MAIN,jdk=jdk7.latest,label=linux/659 > RecoveryManagerStartStopTest hang waiting for byteman rendezvous > ---------------------------------------------------------------- > > Key: JBTM-2250 > URL: https://issues.jboss.org/browse/JBTM-2250 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 6.0.0 > > Attachments: jstack.1125 > > > The test hung running CI job narayana-jdbcobjectstore (jstack output attached). Buiid config details are: > {quote} > Started by upstream project "narayana-jdbcobjectstore" build number 99 > originally caused by: > Started by user anonymous > Building remotely on brandon in workspace /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux > Checkout:linux / /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux - hudson.remoting.Channel at 64cff684:brandon > Using strategy: Default > Last Built Revision: Revision c37dd7bad1eb75837d79f0356baf35d9fae60a81 (origin/master) > Wiping out workspace first. > Cloning the remote Git repository > Cloning repository git://github.com/jbosstm/narayana.git > git --version > git version 1.7.1 > Fetching upstream changes from origin > Commencing build of Revision cda46e475c3ce62243cf7c63e68310923cb1930b (origin/master > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 08:05:04 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 29 Sep 2014 08:05:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2250) RecoveryManagerStartStopTest hang waiting for byteman rendezvous In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2250: -------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > RecoveryManagerStartStopTest hang waiting for byteman rendezvous > ---------------------------------------------------------------- > > Key: JBTM-2250 > URL: https://issues.jboss.org/browse/JBTM-2250 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 6.0.0 > > Attachments: jstack.1125 > > > The test hung running CI job narayana-jdbcobjectstore (jstack output attached). Buiid config details are: > {quote} > Started by upstream project "narayana-jdbcobjectstore" build number 99 > originally caused by: > Started by user anonymous > Building remotely on brandon in workspace /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux > Checkout:linux / /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk7.latest/slave/linux - hudson.remoting.Channel at 64cff684:brandon > Using strategy: Default > Last Built Revision: Revision c37dd7bad1eb75837d79f0356baf35d9fae60a81 (origin/master) > Wiping out workspace first. > Cloning the remote Git repository > Cloning repository git://github.com/jbosstm/narayana.git > git --version > git version 1.7.1 > Fetching upstream changes from origin > Commencing build of Revision cda46e475c3ce62243cf7c63e68310923cb1930b (origin/master > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 08:07:03 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 29 Sep 2014 08:07:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2258) Update the build process to build a binary distribution of Narayana during normal install phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2258: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update the build process to build a binary distribution of Narayana during normal install phase > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2258 > URL: https://issues.jboss.org/browse/JBTM-2258 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > ./build.sh install (or just ./build.sh - install is the default) should build the release zip. > We have removed the JavaDocs from the dist as these are available online (including previous versions) and this is consistent with not including the docs either. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 09:03:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 29 Sep 2014 09:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006855#comment-13006855 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- Kabir Khan changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from POST to MODIFIED > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 09:03:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 29 Sep 2014 09:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006856#comment-13006856 ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- Kabir Khan changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from POST to MODIFIED > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 19:00:16 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 29 Sep 2014 19:00:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007102#comment-13007102 ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- Paul Gier changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from MODIFIED to ON_QA > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 19:00:17 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 29 Sep 2014 19:00:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007106#comment-13007106 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- Paul Gier changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from MODIFIED to ON_QA > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 05:07:02 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 30 Sep 2014 05:07:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2253) Brandon CI node misconfiguration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2253. --------------------------------- Resolution: Done Jonathan has worked some magic on the node and it should be OK now (at least my standalone test works now) so resolving. > Brandon CI node misconfiguration > --------------------------------- > > Key: JBTM-2253 > URL: https://issues.jboss.org/browse/JBTM-2253 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/639/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/ > {code} > 12:39:56,830 ERROR [org.codehaus.stomp.jms.ProtocolConverter] (StompConnect Transport: tcp:///127.0.0.1:44813) Connection is closed: org.codehaus.stomp.jms.ProtocolConverter at 10c10e8 > 12:39:56,831 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///127.0.0.1:44813) Caught an exception: Broken pipe: java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) [rt.jar:1.7.0_51] > at java.net.SocketOutputStream.write(SocketOutputStream.java:159) [rt.jar:1.7.0_51] > at java.io.DataOutputStream.write(DataOutputStream.java:107) [rt.jar:1.7.0_51] > at java.io.FilterOutputStream.write(FilterOutputStream.java:97) [rt.jar:1.7.0_51] > at org.codehaus.stomp.StompMarshaller.marshal(StompMarshaller.java:83) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.onStompFrame(TcpTransport.java:80) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.sendToStomp(ProtocolConverter.java:498) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.jms.ProtocolConverter.onStompFrame(ProtocolConverter.java:209) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:101) [wildfly-blacktie-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 110.88 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.TestTopic > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.162 sec > Running org.jboss.narayana.blacktie.jatmibroker.xatmi.server.BlackTieServerTestCase > Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.248 sec > Results : > Tests in error: > AtmiBrokerEnvXMLTest.testEnv:53 ? UnknownHost brandon.buildnet.ncl.jboss.com: ... > TestConnection.setUp:29 ? Configuration Could not create the orb management fu... > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 08:06:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 30 Sep 2014 08:06:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007266#comment-13007266 ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- Hayk Hovsepyan changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from ON_QA to VERIFIED > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 08:06:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 30 Sep 2014 08:06:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007267#comment-13007267 ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- Hayk Hovsepyan changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from ON_QA to VERIFIED > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329)