[JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #1060 in GitHub
--------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Reopened)
> Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system
> ---------------------------------------------------------------------------------------------
>
> Key: JBTM-2701
> URL: https://issues.jboss.org/browse/JBTM-2701
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Transaction Core
> Affects Versions: 4.17.33
> Environment: JBoss EA P6.4.8
> Reporter: Tom Ross
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2701:
-------------------------------------
Noted that work in this area carried out before as part of JBTM-1354
> Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system
> ---------------------------------------------------------------------------------------------
>
> Key: JBTM-2701
> URL: https://issues.jboss.org/browse/JBTM-2701
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Transaction Core
> Affects Versions: 4.17.33
> Environment: JBoss EA P6.4.8
> Reporter: Tom Ross
> Assignee: Michael Musgrove
> Priority: Minor
> Fix For: 5.next
>
>
> The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default).
> The following signature can be observed in the log file:
> {noformat}
> 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3
> 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord
> 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3
> {noformat}
> It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2735:
-------------------------------------
The clue was in the fact you needed the recovery call first. I suspect this is caused by JBTM-2701. I would say that even when I hold it in the debugger long enough for recovery to happen the test does still fail with: instrumentedTestXAResource.assertKnownInstances(2);
However I see from the log that the Xid was committed twice so I think that aspect may be a test issue. I will work on 2701 first.
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2733:
-------------------------------------
Must state that for recovery to work (especially after using tooling to reset a heuristic) the EIS is expected to follow XA and call xa_recover(START), xa_commit/rb, xa_recover(END)
> Adding section about inflow transactions and EIS interaction
> ------------------------------------------------------------
>
> Key: JBTM-2733
> URL: https://issues.jboss.org/browse/JBTM-2733
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Documentation
> Affects Versions: 5.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
>
> I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of.
> This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2720:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Allow the setting of an initial delay in PeriodRecovery
> -------------------------------------------------------
>
> Key: JBTM-2720
> URL: https://issues.jboss.org/browse/JBTM-2720
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Recovery
> Reporter: Matthew Robson
> Assignee: Tom Jenkinson
> Fix For: 4.17.35, 5.3.4.Final
>
>
> Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers.
> In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster.
> Periodic Recovery currently leverages 2 properties:
> <system-properties>
> <property name="RecoveryEnvironmentBean.periodicRecoveryPeriod" value="120"/>
> <property name="RecoveryEnvironmentBean.recoveryBackoffPeriod" value="10"/>
> </system-properties>
> The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2735:
----------------------------------
Steps to Reproduce:
Crashrecovery testsuite could be used for reproducing the issue
{code}
git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
export JBOSS_HOME=...
mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#jvmCrashAfterPrepare
{code}
was:
Crashrecovery testsuite could be used for reproducing the issue
{code}
git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#jvmCrashAfterPrepare
{code}
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2735:
----------------------------------
Steps to Reproduce:
Crashrecovery testsuite could be used for reproducing the issue
{code}
git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#jvmCrashAfterPrepare
{code}
was:
Crashrecovery testsuite could be used for reproducing the issue
{code}
git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git
mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery#jvmCrashAfterPrepare
{code}
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2735:
-------------------------------------
I am trying to run this test but it won't reboot the server:
{quote}
Running org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.94 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase
jvmCrashAfterPrepare(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 20.748 sec <<< ERROR!
org.jboss.arquillian.container.spi.client.container.LifecycleException: The java process starting the managed server exited unexpectedly with code [1]
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:152)
at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:115)
at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150)
at org.jboss.as.test.jbossts.base.TestBaseOneServer.rebootServer(TestBaseOneServer.java:345)
at org.jboss.as.test.jbossts.base.TestBaseOneServer.rebootServer(TestBaseOneServer.java:314)
at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepare(JcaInflowTransactionTestCase.java:611)
jvmCrashAfterPrepare(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 20.748 sec <<< ERROR!
java.lang.IllegalArgumentException: Deployment with name mock-resource-adapter-test could not be undeployed. Container jbossts must be still running.
at org.jboss.arquillian.container.test.impl.client.deployment.ClientDeployer.undeploy(ClientDeployer.java:129)
at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.doUndeploy(JcaInflowTransactionTestCase.java:201)
Results :
Tests in error:
org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepare(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase)
Run 1: JcaInflowTransactionTestCase.jvmCrashAfterPrepare:611->TestBaseOneServer.rebootServer:314->TestBaseOneServer.rebootServer:345 » Lifecycle
Run 2: JcaInflowTransactionTestCase>TestBaseOneServer.after:260->doUndeploy:201 » IllegalArgument
{quote}
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka edited comment on JBTM-2734 at 8/25/16 5:41 AM:
----------------------------------------------------------------
Thanks for the note. _leaving the XATerminator in a funny state_ made my day ;)
I've already found that when you mentioned that there is a need for {{XATerminator.recover call}}. I changed it to:
* sendRecover(TMSTARTRSCAN)
* sendRecover(TMENDRSCAN)
* sendCommit(xid)
would you consider that correct?
was (Author: ochaloup):
Thanks for the note. _ leaving the XATerminator in a funny state_ made my day ;)
I've already found that when you mentioned that there is a need for {{XATerminator.recover call}}. I changed it to:
* sendRecover(TMSTARTRSCAN)
* sendRecover(TMENDRSCAN)
* sendCommit(xid)
would you consider that correct?
> EIS can't recover transaction when heuristic outcome happens
> ------------------------------------------------------------
>
> Key: JBTM-2734
> URL: https://issues.jboss.org/browse/JBTM-2734
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way
> # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB.
> # transaction is marked to have heuristic result and manual intervention is necessary
> # user calls {{recover}} for participant at such state and its state is changed to _prepared_
> # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store
> This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be
> # EIS propagates EIS TX to Narayana
> # enlisting XAR in Narayana subordinate TX
> # committing EIS TX
> ## It commits Narayana subordinate TX
> # XAR in Narayana TX returns RMERR
> # Narayana returns XA_HEURMIX
> # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared
> # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet
> # EIS should call Narayana via XATerminator::recover()
> ## getting back an Xid that matches to Narayana subordinate TX
> # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid)
> (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_)
> The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on JBTM-2734:
---------------------------------------
Thanks for the note. _ leaving the XATerminator in a funny state_ made my day ;)
I've already found that when you mentioned that there is a need for {{XATerminator.recover call}}. I changed it to:
* sendRecover(TMSTARTRSCAN)
* sendRecover(TMENDRSCAN)
* sendCommit(xid)
would you consider that correct?
> EIS can't recover transaction when heuristic outcome happens
> ------------------------------------------------------------
>
> Key: JBTM-2734
> URL: https://issues.jboss.org/browse/JBTM-2734
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Critical
> Fix For: 5.next
>
>
> For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way
> # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB.
> # transaction is marked to have heuristic result and manual intervention is necessary
> # user calls {{recover}} for participant at such state and its state is changed to _prepared_
> # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store
> This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be
> # EIS propagates EIS TX to Narayana
> # enlisting XAR in Narayana subordinate TX
> # committing EIS TX
> ## It commits Narayana subordinate TX
> # XAR in Narayana TX returns RMERR
> # Narayana returns XA_HEURMIX
> # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared
> # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet
> # EIS should call Narayana via XATerminator::recover()
> ## getting back an Xid that matches to Narayana subordinate TX
> # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid)
> (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_)
> The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months