May 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2583) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2583. ------------------------------- Resolution: Done > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2583 > URL: https://issues.jboss.org/browse/JBTM-2583 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.2.17.Final, 5.3.0.Final > > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > > * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2672) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2672?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2672: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2672 > URL: https://issues.jboss.org/browse/JBTM-2672 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.2.14.Final > Reporter: Bartosz Baranowski > Fix For: 5.2.17.Final > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2672) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBTM-2672?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski updated JBTM-2672: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1011 > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2672 > URL: https://issues.jboss.org/browse/JBTM-2672 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.2.14.Final > Reporter: Bartosz Baranowski > Fix For: 5.2.17.Final > > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2672) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/JBTM-2672?focusedWorklogId=12435911&page=... ] Bartosz Baranowski logged work on JBTM-2672: -------------------------------------------- Author: Bartosz Baranowski Created on: 18/May/16 3:27 AM Start Date: 18/May/16 3:27 AM Worklog Time Spent: 4 hours Issue Time Tracking ------------------- Remaining Estimate: 0 minutes Time Spent: 4 hours Worklog Id: (was: 12435911) > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2672 > URL: https://issues.jboss.org/browse/JBTM-2672 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.2.14.Final > Reporter: Bartosz Baranowski > Fix For: 5.2.17.Final > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2672) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created JBTM-2672: ---------------------------------------- Summary: Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection Key: JBTM-2672 URL: https://issues.jboss.org/browse/JBTM-2672 Project: JBoss Transaction Manager Issue Type: Bug Components: Recovery Affects Versions: 5.2.14.Final Reporter: Bartosz Baranowski Fix For: 5.2.17.Final Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2579?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2579: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1325726|https://bugzilla.redhat.com/show_bug.cgi?id=1325726] from ON_QA to VERIFIED > 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.2.9.Final > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2655) QA suite failure: TestGroup_txcore_recovery (JDBC store)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2655?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2655: -------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Tom Jenkinson Resolution: Done > QA suite failure: TestGroup_txcore_recovery (JDBC store) > -------------------------------------------------------- > > Key: JBTM-2655 > URL: https://issues.jboss.org/browse/JBTM-2655 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-jdbcobje... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 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 commented on JBTM-2575: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1289386|https://bugzilla.redhat.com/show_bug.cgi?id=1289386] from ON_QA to VERIFIED > 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.2.9.Final > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2668) Entity manager does not join transaction properly in JTA and Hibernate quickstart

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2668?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Gytis Trikleris created pull request #163 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Entity manager does not join transaction properly in JTA and Hibernate quickstart > --------------------------------------------------------------------------------- > > Key: JBTM-2668 > URL: https://issues.jboss.org/browse/JBTM-2668 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > To reproduce begin transaction at the start of TestCase.testJpa method and roll it back just before assertion. During the abort in BasicAction pending list is empty and no resources are rolled back. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2671) TXBridge quickstart execution steps are inaccurate

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-2671: ------------------------------------- Summary: TXBridge quickstart execution steps are inaccurate Key: JBTM-2671 URL: https://issues.jboss.org/browse/JBTM-2671 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator, TxBridge, XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next Execution steps for both wsat-jta-multi_hop and wsat-jta-multi_service quickstarts tells to start WildFly in one console and then execute the test with managed Arquillian container. Which is obviously wrong. We shouldn't suggest to start the container manually, but only use the managed container. Also, it might be good to not redirect output to the file, but instead print it directly and use egrep as showed in the current execution steps. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues May 2016