April 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3002) XTS integration tests fails on: SoapFault11: Callback wasn't triggered

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3002?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka closed JBTM-3002. --------------------------------- Resolution: Out of Date With changes in WFLY introducing the WFCORE 5.0.0.Alpha2 the trouble was fixed. > XTS integration tests fails on: SoapFault11: Callback wasn't triggered > ---------------------------------------------------------------------- > > Key: JBTM-3002 > URL: https://issues.jboss.org/browse/JBTM-3002 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > There is failing XTS tests with {{com.arjuna.webservices11.SoapFault11: Receiver[Callback wasn't triggered]}}. > This could be cause by some changes in WFLY server or it's some coincidence of wrong integration on the Narayana side. > {code} > INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-1) Creating Service {http://fabrikam123.com}ParticipantService from WSDL: vfs:/content/interop11.war/WEB-INF/classes/com/jboss/transaction/txinterop/webservices/atinterop/generated/wsdl/interopat-participant-binding.wsdl > INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-1) Creating Service {http://fabrikam123.com}ParticipantService from WSDL: vfs:/content/interop11.war/WEB-INF/classes/com/jboss/transaction/txinterop/webservices/atinterop/generated/wsdl/interopat-participant-binding.wsdl > INFO [stdout] (default task-2) KEV: processing SOAP action http://fabrikam123.com/CompletionCommit > ERROR [stderr] (default task-2) Proxy Listener Service: org.apache.http.client.ClientProtocolException > ERROR [stderr] (default task-2) org.apache.http.client.ClientProtocolException > ERROR [stderr] (default task-2) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > ERROR [stderr] (default task-2) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > ERROR [stderr] (default task-2) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > ERROR [stderr] (default task-2) at org.wildfly.url.http.HttpClientURLConnection.doRequest(HttpClientURLConnection.java:189) > ERROR [stderr] (default task-2) at org.wildfly.url.http.HttpClientURLConnection.connect(HttpClientURLConnection.java:205) > ERROR [stderr] (default task-2) at com.jboss.transaction.txinterop.proxy.ProxyListenerService.doPost(ProxyListenerService.java:184) > ERROR [stderr] (default task-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > ERROR [stderr] (default task-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:67) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > ERROR [stderr] (default task-2) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > ERROR [stderr] (default task-2) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > ERROR [stderr] (default task-2) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360) > ERROR [stderr] (default task-2) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) > ERROR [stderr] (default task-2) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > ERROR [stderr] (default task-2) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > ERROR [stderr] (default task-2) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > ERROR [stderr] (default task-2) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > ERROR [stderr] (default task-2) at java.lang.Thread.run(Thread.java:748) > ERROR [stderr] (default task-2) Caused by: org.apache.http.ProtocolException: Content-Length header already present > ERROR [stderr] (default task-2) at org.apache.http.protocol.RequestContent.process(RequestContent.java:96) > ERROR [stderr] (default task-2) at org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:132) > ERROR [stderr] (default task-2) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:182) > ERROR [stderr] (default task-2) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) > ERROR [stderr] (default task-2) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) > ERROR [stderr] (default task-2) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) > ERROR [stderr] (default task-2) ... 48 more > INFO [stdout] (default task-1) KEV: removed conversation c1 > INFO [stdout] (Thread-0) TransformListener() : handling connection on port 9091 > INFO [stdout] (Thread-0) retransforming org.jboss.jbossts.xts.bytemanSupport.participantReadOnly.ParticipantCompletionReadOnlyRules > INFO [stdout] (Thread-0) retransforming com.arjuna.wst11.messaging.ParticipantProcessorImpl > INFO [stdout] (Thread-0) retransforming com.arjuna.wst11.messaging.CoordinatorProcessorImpl > INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/interop11' from server 'default-server' > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3002) XTS integration tests fails on: SoapFault11: Callback wasn't triggered

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3002?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-3002: --------------------------------------- with reverting the fix for the WFCORE-3658 (https://github.com/wildfly/wildfly-core/pull/3188) which is part of the release WildFly Core 5.0.0.Alpha2 (8a908041a7, https://github.com/wildfly/wildfly/pull/11074) the call for the {{HttpURLConnection.isRestrictedHeader}} is returned back to remove the headers which the apache implementation of outgoing http connection does not expect. After that update the XTS works fine now. > XTS integration tests fails on: SoapFault11: Callback wasn't triggered > ---------------------------------------------------------------------- > > Key: JBTM-3002 > URL: https://issues.jboss.org/browse/JBTM-3002 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > There is failing XTS tests with {{com.arjuna.webservices11.SoapFault11: Receiver[Callback wasn't triggered]}}. > This could be cause by some changes in WFLY server or it's some coincidence of wrong integration on the Narayana side. > {code} > INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-1) Creating Service {http://fabrikam123.com}ParticipantService from WSDL: vfs:/content/interop11.war/WEB-INF/classes/com/jboss/transaction/txinterop/webservices/atinterop/generated/wsdl/interopat-participant-binding.wsdl > INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-1) Creating Service {http://fabrikam123.com}ParticipantService from WSDL: vfs:/content/interop11.war/WEB-INF/classes/com/jboss/transaction/txinterop/webservices/atinterop/generated/wsdl/interopat-participant-binding.wsdl > INFO [stdout] (default task-2) KEV: processing SOAP action http://fabrikam123.com/CompletionCommit > ERROR [stderr] (default task-2) Proxy Listener Service: org.apache.http.client.ClientProtocolException > ERROR [stderr] (default task-2) org.apache.http.client.ClientProtocolException > ERROR [stderr] (default task-2) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > ERROR [stderr] (default task-2) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > ERROR [stderr] (default task-2) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > ERROR [stderr] (default task-2) at org.wildfly.url.http.HttpClientURLConnection.doRequest(HttpClientURLConnection.java:189) > ERROR [stderr] (default task-2) at org.wildfly.url.http.HttpClientURLConnection.connect(HttpClientURLConnection.java:205) > ERROR [stderr] (default task-2) at com.jboss.transaction.txinterop.proxy.ProxyListenerService.doPost(ProxyListenerService.java:184) > ERROR [stderr] (default task-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) > ERROR [stderr] (default task-2) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:67) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > ERROR [stderr] (default task-2) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > ERROR [stderr] (default task-2) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > ERROR [stderr] (default task-2) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > ERROR [stderr] (default task-2) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1523) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > ERROR [stderr] (default task-2) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > ERROR [stderr] (default task-2) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360) > ERROR [stderr] (default task-2) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830) > ERROR [stderr] (default task-2) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > ERROR [stderr] (default task-2) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > ERROR [stderr] (default task-2) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > ERROR [stderr] (default task-2) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > ERROR [stderr] (default task-2) at java.lang.Thread.run(Thread.java:748) > ERROR [stderr] (default task-2) Caused by: org.apache.http.ProtocolException: Content-Length header already present > ERROR [stderr] (default task-2) at org.apache.http.protocol.RequestContent.process(RequestContent.java:96) > ERROR [stderr] (default task-2) at org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:132) > ERROR [stderr] (default task-2) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:182) > ERROR [stderr] (default task-2) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) > ERROR [stderr] (default task-2) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) > ERROR [stderr] (default task-2) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) > ERROR [stderr] (default task-2) ... 48 more > INFO [stdout] (default task-1) KEV: removed conversation c1 > INFO [stdout] (Thread-0) TransformListener() : handling connection on port 9091 > INFO [stdout] (Thread-0) retransforming org.jboss.jbossts.xts.bytemanSupport.participantReadOnly.ParticipantCompletionReadOnlyRules > INFO [stdout] (Thread-0) retransforming com.arjuna.wst11.messaging.ParticipantProcessorImpl > INFO [stdout] (Thread-0) retransforming com.arjuna.wst11.messaging.CoordinatorProcessorImpl > INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/interop11' from server 'default-server' > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3006) Tooling delete operation can left hanging remote txn branch when it was subordinate prepared participant

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3006?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-3006: --------------------------------------- Another way could be removing even prepared branches on the mbean delete operation. This approach was introduced in commit: https://github.com/ochaloup/narayana/commit/9a678044b454bbfc4154430e39c51... But this approach is not ideal one as the tooling should not be responsible for finishing prepared transactions. That's the work for the recovery. > Tooling delete operation can left hanging remote txn branch when it was subordinate prepared participant > -------------------------------------------------------------------------------------------------------- > > Key: JBTM-3006 > URL: https://issues.jboss.org/browse/JBTM-3006 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.8.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Attachments: data-subordinate.zip, jboss-cli-commands.txt, standalone-full.xml > > > When administrator decides to call 'delete' in WFLY (or as jmx mbean call) and the transaction is subordinate (meaning started by another server and the context was propagated to this one) then if they are in heuristic state the transaction is removed from the narayana object store and from the RA. If the transaction is in prepared state then participant is removed from narayana object store (that could be influenced by settings of {{ignoreMBeanHeuristics}} property, see https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) but the transaction branch at the RA is left untouched - [XAResource.forget|https://docs.oracle.com/javaee/7/api/javax/transaction/...] is called but it fails at the participant remote branch (see [XA spec|pubs.opengroup.org/onlinepubs/009680699/toc.pdf) - the XA spec permits calling {{forget}} only on heuristically finished branches but this is still {{prepared}}. > The final outcome is that there is removed record from Narayana object store and left untouched in-doubt (prepared) remote branch. > Such record should be handled by recovery (ideally) the {{SubordinateJTAXAResourceOrphanFilter}} votes for rollback but then the {{SubordinationManagerXAResourceOrphanFilter}} forces to leave it as it is. Thus such record will be handing forever. > {code} > TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff0a280466:-51bd8cd:5aa92b2b:1c, node_name=1, branch_uid=0:ffff0a280466:758014d3:5aa92b2f:26, subordinatenodename=2, eis_name=java:/JmsXA NodeId:2bda713c-2790-11e8-8b4f-0a0027000000 > > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter voted ROLLBACK > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff0a280466:-51bd8cd:5aa92b2b:1c, node_name=1, branch_uid=0:ffff0a280466:758014d3:5aa92b2f:26, subordinatenodename=2, eis_name=java:/JmsXA NodeId:2bda713c-2790-11e8-8b4f-0a0027000000 > is 2 > TRACE [com.arjuna.ats.jta] (Periodic Recovery) TransactionImple.getStatus: javax.transaction.Status.STATUS_UNKNOWN > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinationManagerXAResourceOrphanFilter voted LEAVE_ALONE > TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper@3397522a 1521650139598 1521650140600 true > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3006) Tooling delete operation can left hanging remote txn branch when it was subordinate prepared participant

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3006?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-3006: --------------------------------------- {{SubordinationManagerXAResourceOrphanFilter}} votes for leaving and I can see there the reason is that the periodic recovery gathers all the subordinate transactions under the list of imported transactions[1] while then when the transaction is checked if it's orphan[2] the transaction importer can see the transaction is in the list[3] and does not permit the orphan filtering to rollback. If I'm not misguided I think the remove operation[4] should consider removing the the txn record from the importer _transactions[3] set. I was investigating about that but the mbean operations can't see (probably because of classpath) at the classes under 'jta' package where {{SuborindationManager}}[5] resides (where the {{TransactionImporter}}[1] could be withdrawn from). Then I was thinking if the recovery module {{SubordinateAtomicActionRecoveryModule}} should not remove the transactions from the importer set when it adds them there[6]. But I haven't found a way[7] to do it so. I'm thinking if the orphan filter[2] could not check directly the object store and if the transaction does not exist then it can be rolled-back. But such solution would bypass the importer which I'm not sure if it's right. [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... [2] https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... [3] https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... [4] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes... [5] https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... [6] https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... [7] https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... > Tooling delete operation can left hanging remote txn branch when it was subordinate prepared participant > -------------------------------------------------------------------------------------------------------- > > Key: JBTM-3006 > URL: https://issues.jboss.org/browse/JBTM-3006 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.8.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Attachments: data-subordinate.zip, jboss-cli-commands.txt, standalone-full.xml > > > When administrator decides to call 'delete' in WFLY (or as jmx mbean call) and the transaction is subordinate (meaning started by another server and the context was propagated to this one) then if they are in heuristic state the transaction is removed from the narayana object store and from the RA. If the transaction is in prepared state then participant is removed from narayana object store (that could be influenced by settings of {{ignoreMBeanHeuristics}} property, see https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) but the transaction branch at the RA is left untouched - [XAResource.forget|https://docs.oracle.com/javaee/7/api/javax/transaction/...] is called but it fails at the participant remote branch (see [XA spec|pubs.opengroup.org/onlinepubs/009680699/toc.pdf) - the XA spec permits calling {{forget}} only on heuristically finished branches but this is still {{prepared}}. > The final outcome is that there is removed record from Narayana object store and left untouched in-doubt (prepared) remote branch. > Such record should be handled by recovery (ideally) the {{SubordinateJTAXAResourceOrphanFilter}} votes for rollback but then the {{SubordinationManagerXAResourceOrphanFilter}} forces to leave it as it is. Thus such record will be handing forever. > {code} > TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff0a280466:-51bd8cd:5aa92b2b:1c, node_name=1, branch_uid=0:ffff0a280466:758014d3:5aa92b2f:26, subordinatenodename=2, eis_name=java:/JmsXA NodeId:2bda713c-2790-11e8-8b4f-0a0027000000 > > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter voted ROLLBACK > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff0a280466:-51bd8cd:5aa92b2b:1c, node_name=1, branch_uid=0:ffff0a280466:758014d3:5aa92b2f:26, subordinatenodename=2, eis_name=java:/JmsXA NodeId:2bda713c-2790-11e8-8b4f-0a0027000000 > is 2 > TRACE [com.arjuna.ats.jta] (Periodic Recovery) TransactionImple.getStatus: javax.transaction.Status.STATUS_UNKNOWN > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinationManagerXAResourceOrphanFilter voted LEAVE_ALONE > TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper@3397522a 1521650139598 1521650140600 true > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3006) Tooling delete operation can left hanging remote txn branch when it was subordinate prepared participant

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-3006: ------------------------------------- Summary: Tooling delete operation can left hanging remote txn branch when it was subordinate prepared participant Key: JBTM-3006 URL: https://issues.jboss.org/browse/JBTM-3006 Project: JBoss Transaction Manager Issue Type: Bug Components: Tooling Affects Versions: 5.8.0.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor Attachments: data-subordinate.zip, jboss-cli-commands.txt, standalone-full.xml When administrator decides to call 'delete' in WFLY (or as jmx mbean call) and the transaction is subordinate (meaning started by another server and the context was propagated to this one) then if they are in heuristic state the transaction is removed from the narayana object store and from the RA. If the transaction is in prepared state then participant is removed from narayana object store (that could be influenced by settings of {{ignoreMBeanHeuristics}} property, see https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) but the transaction branch at the RA is left untouched - [XAResource.forget|https://docs.oracle.com/javaee/7/api/javax/transaction/...] is called but it fails at the participant remote branch (see [XA spec|pubs.opengroup.org/onlinepubs/009680699/toc.pdf) - the XA spec permits calling {{forget}} only on heuristically finished branches but this is still {{prepared}}. The final outcome is that there is removed record from Narayana object store and left untouched in-doubt (prepared) remote branch. Such record should be handled by recovery (ideally) the {{SubordinateJTAXAResourceOrphanFilter}} votes for rollback but then the {{SubordinationManagerXAResourceOrphanFilter}} forces to leave it as it is. Thus such record will be handing forever. {code} TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff0a280466:-51bd8cd:5aa92b2b:1c, node_name=1, branch_uid=0:ffff0a280466:758014d3:5aa92b2f:26, subordinatenodename=2, eis_name=java:/JmsXA NodeId:2bda713c-2790-11e8-8b4f-0a0027000000 > DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter voted ROLLBACK DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff0a280466:-51bd8cd:5aa92b2b:1c, node_name=1, branch_uid=0:ffff0a280466:758014d3:5aa92b2f:26, subordinatenodename=2, eis_name=java:/JmsXA NodeId:2bda713c-2790-11e8-8b4f-0a0027000000 > is 2 TRACE [com.arjuna.ats.jta] (Periodic Recovery) TransactionImple.getStatus: javax.transaction.Status.STATUS_UNKNOWN DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinationManagerXAResourceOrphanFilter voted LEAVE_ALONE TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper@3397522a 1521650139598 1521650140600 true {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3005) Add a quickstart showing the Tomcat and DBCP2

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3005?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-3005: ---------------------------- Environment: (was: This quickstart needs to show how to use the DBCP2 in Tomcat to support the XA transaction.) > Add a quickstart showing the Tomcat and DBCP2 > --------------------------------------------- > > Key: JBTM-3005 > URL: https://issues.jboss.org/browse/JBTM-3005 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3005) Add a quickstart showing the Tomcat and DBCP2

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-3005?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-3005: ---------------------------- Description: This quickstart needs to show how to use the DBCP2 in Tomcat to support the XA transaction. > Add a quickstart showing the Tomcat and DBCP2 > --------------------------------------------- > > Key: JBTM-3005 > URL: https://issues.jboss.org/browse/JBTM-3005 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > This quickstart needs to show how to use the DBCP2 in Tomcat to support the XA transaction. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3005) Add a quickstart showing the Tomcat and DBCP2

by Amos Feng (JIRA)

Amos Feng created JBTM-3005: ------------------------------- Summary: Add a quickstart showing the Tomcat and DBCP2 Key: JBTM-3005 URL: https://issues.jboss.org/browse/JBTM-3005 Project: JBoss Transaction Manager Issue Type: Task Components: Demonstrator Environment: This quickstart needs to show how to use the DBCP2 in Tomcat to support the XA transaction. Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2018