August 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2717. --------------------------------- Fix Version/s: (was: 5.next) Resolution: Won't Fix This seems like a test issue. I had a look at the test and but a break point here: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/tests/class... The issue is that the removal of the helper and the subsequent checking of the getScanState its not atomic so it can give erroneous responses. > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2717: ----------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2717: ----------------------------------- Assignee: Michael Musgrove > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2725: -------------------------------- Forum Reference: https://developer.jboss.org/thread/271935 > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2725: ------------------------------------- This was to match its behaviour with the standard local JTA variant. > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[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.... ] Work on JBTM-2334 started by Gytis Trikleris. --------------------------------------------- > 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 > # Provide custom Narayana configuration file for Tomcat > # Provide context.xml with required configurations: lifecycle listener, UserTransaction, SynchronizationRegistry > # Add pooling to transactional driver (either implement it or use some library) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2725: ---------------------------------------- See the linked PR for the actual fix which was to return success from a rollback attempt if the transaction was already in any of the states ABORTED, ABORTING or H_ROLLBACK. > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[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 closed JBTM-2735. --------------------------------- Resolution: Rejected Thanks Tom for investigation and help. Confirming this is a test issue as our test framework does not work correctly with multiple TestXAResources. I'm sorry for inconveniences. > 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)

8 years, 3 months

1
0
0 / 0

[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: -------------------------------- Fix Version/s: 5.2.18.Final > 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.2.18.Final, 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)

8 years, 3 months

1
0
0 / 0

[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 created a pull on JBTM-2701 https://github.com/jbosstm/narayana/pull/1060 - it seems to make your test pass too. However, I think there is an issue with the test which I fixed as follows. {quote} [tom@wicket eap-tests-transactions](master)(14:51:41) $ git diff jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java diff --git a/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java b/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java index e20407e..9aa6dfc 100644 --- a/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java +++ b/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java @@ -581,7 +581,7 @@ public class JcaInflowTransactionTestCase extends TestBaseOneServer { * <b>TODO:</b> it's expected this test will need to be tuned after discussion on raised jira */ @Test - @Ignore("JBEAP-5641/JBTM-2735: EIS can't finish all participants of inflow in-doubt transaction after jvm crash") +// @Ignore("JBEAP-5641/JBTM-2735: EIS can't finish all participants of inflow in-doubt transaction after jvm crash") public void jvmCrashAfterPrepare() throws Throwable { JBossLogParserSetup.addSkipPatternForTest(".*XAER_RMFAIL.*", ".*javax.transaction.xa.XAException.*"); @@ -620,16 +620,16 @@ public class JcaInflowTransactionTestCase extends TestBaseOneServer { // I think yes, as for EIS the transaction managed by app server TM is in fact one participant Assert.assertEquals("One xid should be returned", "1", numberOfXids.get()); - doRecovery(); +// doRecovery(); // the participant was recovered -> it's in prepare state - let's commit it sendCommit(xidNumId); // xa resource should be committed - instrumentedTestXAResource.assertKnownInstances(2); + instrumentedTestXAResource.assertKnownInstances(1); instrumentedTestXAResource.assertMethodNotCalled("rollback"); instrumentedTestXAResource.assertMethodNotCalled("prepare"); - instrumentedTestXAResource.assertMethodCallCount("Both two TestXAResources should be committed", "commit", 1); + instrumentedTestXAResource.assertMethodCallCount("Both two TestXAResources should be committed", "commit", 2); // and logs should be empty (even jboss cli should say so) TMOperations ops = ManagementClientSetup.getTMOperations(TestProperties.CRASHREC_CONTAINER); {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)

8 years, 3 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 August 2016