December 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2575) When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2575?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2575: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1289386|https://bugzilla.redhat.com/show_bug.cgi?id=1289386] from NEW to ASSIGNED > When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2575 > URL: https://issues.jboss.org/browse/JBTM-2575 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 4.17.31, 5.next > > > There is a check in the subordinate orphan detection that not only checks for matching gtrid but also for matching subordinate name. This will not match correctly for an intermediary node. E.g. > a->b b->c > When b scans c the xid it gets back will have subordinate name of c, b will look in its object store and match the subordinate on gtrid but the subordinate node ID in b subordinateatomicaction will be "b". > This check is actually superfluous anyway. We already know that the Xid returned from c was for b because of transport level checks. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2575) When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2575?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBTM-2575: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1289386 Bugzilla Update: Perform > When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2575 > URL: https://issues.jboss.org/browse/JBTM-2575 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 4.17.31, 5.next > > > There is a check in the subordinate orphan detection that not only checks for matching gtrid but also for matching subordinate name. This will not match correctly for an intermediary node. E.g. > a->b b->c > When b scans c the xid it gets back will have subordinate name of c, b will look in its object store and match the subordinate on gtrid but the subordinate node ID in b subordinateatomicaction will be "b". > This check is actually superfluous anyway. We already know that the Xid returned from c was for b because of transport level checks. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2575) When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2575?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2575: ----------------------------------- Assignee: Tom Jenkinson > When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2575 > URL: https://issues.jboss.org/browse/JBTM-2575 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 4.17.31, 5.next > > > There is a check in the subordinate orphan detection that not only checks for matching gtrid but also for matching subordinate name. This will not match correctly for an intermediary node. E.g. > a->b b->c > When b scans c the xid it gets back will have subordinate name of c, b will look in its object store and match the subordinate on gtrid but the subordinate node ID in b subordinateatomicaction will be "b". > This check is actually superfluous anyway. We already know that the Xid returned from c was for b because of transport level checks. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2575) When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2575?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2575: -------------------------------- Fix Version/s: 5.next (was: 5.later) > When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2575 > URL: https://issues.jboss.org/browse/JBTM-2575 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Tom Jenkinson > Priority: Blocker > Fix For: 4.17.31, 5.next > > > There is a check in the subordinate orphan detection that not only checks for matching gtrid but also for matching subordinate name. This will not match correctly for an intermediary node. E.g. > a->b b->c > When b scans c the xid it gets back will have subordinate name of c, b will look in its object store and match the subordinate on gtrid but the subordinate node ID in b subordinateatomicaction will be "b". > This check is actually superfluous anyway. We already know that the Xid returned from c was for b because of transport level checks. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2579) Throw XAException in XATerminator::commit if a wrapped resource fails transiently

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2579?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2579: -------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/959/, https://github.com/jbosstm/narayana/pull/960 (was: https://github.com/jbosstm/narayana/pull/959/) > Throw XAException in XATerminator::commit if a wrapped resource fails transiently > --------------------------------------------------------------------------------- > > Key: JBTM-2579 > URL: https://issues.jboss.org/browse/JBTM-2579 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.31, 5.next > > > It is possible for a resource that we are wrapping to return say XA_RETRY or XA_RMFAIL and therefore end up in the BasicAction failed list. However there is no error returned from commit in this circumstance as the recovery manager should ensure a consistent outcome. > The reason this becomes a problem for JTA and XATerminator in particular is that as no error is returned a parent coordinator will assume the branch completed successfully. In the future when it calls XATerminator::recover though this branch will be returned and detected as an orphan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2579) Throw XAException in XATerminator::commit if a wrapped resource fails transiently

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2579?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2579: -------------------------------- Release Notes Text: A consequence of the agreed fix is that the afterCompletion will no longer run because the transaction is not completed inline and therefore is left to the recovery manager, > Throw XAException in XATerminator::commit if a wrapped resource fails transiently > --------------------------------------------------------------------------------- > > Key: JBTM-2579 > URL: https://issues.jboss.org/browse/JBTM-2579 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.31, 5.next > > > It is possible for a resource that we are wrapping to return say XA_RETRY or XA_RMFAIL and therefore end up in the BasicAction failed list. However there is no error returned from commit in this circumstance as the recovery manager should ensure a consistent outcome. > The reason this becomes a problem for JTA and XATerminator in particular is that as no error is returned a parent coordinator will assume the branch completed successfully. In the future when it calls XATerminator::recover though this branch will be returned and detected as an orphan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2574) invalid local variable binding $this AT ENTRY injection when the tests run with the jacoco

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2574?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2574: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > invalid local variable binding $this AT ENTRY injection when the tests run with the jacoco > ------------------------------------------------------------------------------------------ > > Key: JBTM-2574 > URL: https://issues.jboss.org/browse/JBTM-2574 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The detail should see in the discuss JBTM-2553. The workaround is use the $0 instead of $this now. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2573) Can not set the right jbossts properties file when running the commitmarkable test under the codeCoverage

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2573?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2573: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Can not set the right jbossts properties file when running the commitmarkable test under the codeCoverage > --------------------------------------------------------------------------------------------------------- > > Key: JBTM-2573 > URL: https://issues.jboss.org/browse/JBTM-2573 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > currently the ArjunaJTA/jta commitmarkable tests fails when running under the codeCoverage. The root cause is that the jbossts properties file does not set to the "commitmarkableresourcejbossts-properties.xml". > The surefire-plugin config the system property com.arjuna.ats.arjuna.common.propertiesFile with "jbossts-properties.xml" in the codeCoverage profile > https://github.com/jbosstm/narayana/blob/master/pom.xml#L645 > So the https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/tests/class... > {code} > resetPropertiesFile = System > .getProperty("com.arjuna.ats.arjuna.common.propertiesFile"); > if (resetPropertiesFile == null) { > System.setProperty("com.arjuna.ats.arjuna.common.propertiesFile", > "commitmarkableresourcejbossts-properties.xml"); > } > {code} > the resetPropertiesFile does not be null and the if check statement is false, so the System.setProperty(...) can not run and the property is still the jbossts-properties.xml. > the resetPropertiesFile could be used to revert to the origin value in the tearDown() > https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/tests/class... > {code} > if (resetPropertiesFile != null) { > System.setProperty("com.arjuna.ats.arjuna.common.propertiesFile", > resetPropertiesFile); > } else { > System.clearProperty("com.arjuna.ats.arjuna.common.propertiesFile"); > } > {code} > This failure does not happen in the default profile as the surefire-plugin does not set this system property in the profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2574) invalid local variable binding $this AT ENTRY injection when the tests run with the jacoco

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2574?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2574: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/954 > invalid local variable binding $this AT ENTRY injection when the tests run with the jacoco > ------------------------------------------------------------------------------------------ > > Key: JBTM-2574 > URL: https://issues.jboss.org/browse/JBTM-2574 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The detail should see in the discuss JBTM-2553. The workaround is use the $0 instead of $this now. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2573) Can not set the right jbossts properties file when running the commitmarkable test under the codeCoverage

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2573?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2573: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/954 > Can not set the right jbossts properties file when running the commitmarkable test under the codeCoverage > --------------------------------------------------------------------------------------------------------- > > Key: JBTM-2573 > URL: https://issues.jboss.org/browse/JBTM-2573 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > currently the ArjunaJTA/jta commitmarkable tests fails when running under the codeCoverage. The root cause is that the jbossts properties file does not set to the "commitmarkableresourcejbossts-properties.xml". > The surefire-plugin config the system property com.arjuna.ats.arjuna.common.propertiesFile with "jbossts-properties.xml" in the codeCoverage profile > https://github.com/jbosstm/narayana/blob/master/pom.xml#L645 > So the https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/tests/class... > {code} > resetPropertiesFile = System > .getProperty("com.arjuna.ats.arjuna.common.propertiesFile"); > if (resetPropertiesFile == null) { > System.setProperty("com.arjuna.ats.arjuna.common.propertiesFile", > "commitmarkableresourcejbossts-properties.xml"); > } > {code} > the resetPropertiesFile does not be null and the if check statement is false, so the System.setProperty(...) can not run and the property is still the jbossts-properties.xml. > the resetPropertiesFile could be used to revert to the origin value in the tearDown() > https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/tests/class... > {code} > if (resetPropertiesFile != null) { > System.setProperty("com.arjuna.ats.arjuna.common.propertiesFile", > resetPropertiesFile); > } else { > System.clearProperty("com.arjuna.ats.arjuna.common.propertiesFile"); > } > {code} > This failure does not happen in the default profile as the surefire-plugin does not set this system property in the profile. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 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 December 2015