[JBoss JIRA] (JBTM-2770) Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2770:
----------------------------------
Attachment: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log
> Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource
> ------------------------------------------------------------------------
>
> Key: JBTM-2770
> URL: https://issues.jboss.org/browse/JBTM-2770
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Blocker
> Attachments: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log
>
>
> I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final)
> The scenario which I run is following
> {quote}
> * enlist test xa resource
> * enlist cmr db resource
> * prepare cmr db resource
> * prepare test xa resource
> * commit cmr db resource
> * crash app server
> * start server and halt connection to DB
> * do recovery of test xa resource which is expected being committed
> {quote}
> What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation).
> In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback.
> {code}
> 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBTM-2770) Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka reassigned JBTM-2770:
-------------------------------------
Assignee: Tom Jenkinson
> Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource
> ------------------------------------------------------------------------
>
> Key: JBTM-2770
> URL: https://issues.jboss.org/browse/JBTM-2770
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
> Priority: Blocker
>
> I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final)
> The scenario which I run is following
> {quote}
> * enlist test xa resource
> * enlist cmr db resource
> * prepare cmr db resource
> * prepare test xa resource
> * commit cmr db resource
> * crash app server
> * start server and halt connection to DB
> * do recovery of test xa resource which is expected being committed
> {quote}
> What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation).
> In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback.
> {code}
> 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBTM-2770) Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2770:
-------------------------------------
Summary: Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource
Key: JBTM-2770
URL: https://issues.jboss.org/browse/JBTM-2770
Project: JBoss Transaction Manager
Issue Type: Bug
Reporter: Ondra Chaloupka
Priority: Blocker
I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final)
The scenario which I run is following
{quote}
* enlist test xa resource
* enlist cmr db resource
* prepare cmr db resource
* prepare test xa resource
* commit cmr db resource
* crash app server
* start server and halt connection to DB
* do recovery of test xa resource which is expected being committed
{quote}
What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation).
In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback.
{code}
2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-2334:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Improve ease of use within Tomcat
> ---------------------------------
>
> Key: JBTM-2334
> URL: https://issues.jboss.org/browse/JBTM-2334
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTA
> Reporter: Mark Little
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
>
> Initial requirements:
> # Implement a Narayana Tomcat module which provides an archive with all dependencies necessary for deployment on Tomcat: common, core, jta, jdbc, cdi, spi, jms (optional)
> # Implement Tomcat lifecycle listener to bootstrap TM and RM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2769:
----------------------------------
Description:
I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}.
I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way).
ad 1.
* JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit
This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned.
This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test.
ad 2.
* JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted
The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown.
{code}
2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603)
at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871)
at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
{code}
was:
I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}.
I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way).
1)
* JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit
This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned.
This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test.
2)
* JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted
*
The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown.
{code}
2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603)
at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871)
at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
{code}
> Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2769
> URL: https://issues.jboss.org/browse/JBTM-2769
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
> Attachments: JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log, JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log
>
>
> I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}.
> I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way).
> ad 1.
> * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit
> This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned.
> This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test.
> ad 2.
> * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted
> The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown.
> {code}
> 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2769:
----------------------------------
Attachment: JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log
JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log
> Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2769
> URL: https://issues.jboss.org/browse/JBTM-2769
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
> Attachments: JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log, JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log
>
>
> I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}.
> I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way).
> 1)
> * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit
> This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned.
> This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test.
> 2)
> * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted
> *
> The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown.
> {code}
> 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka reassigned JBTM-2769:
-------------------------------------
Assignee: Michael Musgrove
> Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2769
> URL: https://issues.jboss.org/browse/JBTM-2769
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Assignee: Michael Musgrove
> Priority: Blocker
>
> I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}.
> I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way).
> 1)
> * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit
> This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned.
> This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test.
> 2)
> * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted
> *
> The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown.
> {code}
> 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2769:
----------------------------------
Affects Version/s: 5.3.5.Final
> Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2769
> URL: https://issues.jboss.org/browse/JBTM-2769
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.5.Final
> Reporter: Ondra Chaloupka
> Priority: Blocker
>
> I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}.
> I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way).
> 1)
> * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit
> This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned.
> This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test.
> 2)
> * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted
> *
> The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown.
> {code}
> 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2769:
-------------------------------------
Summary: Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic
Key: JBTM-2769
URL: https://issues.jboss.org/browse/JBTM-2769
Project: JBoss Transaction Manager
Issue Type: Bug
Reporter: Ondra Chaloupka
Priority: Blocker
I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}.
I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way).
1)
* JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit
This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned.
This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test.
2)
* JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted
*
The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown.
{code}
2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603)
at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871)
at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months