April 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3138) XTS txbridge does not run commit when succesfully prepared on crash recovery

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3138?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3138: ----------------------------------- Steps to Reproduce: >From the PR https://github.com/jbosstm/narayana/pull/1391 running the test {code} mvn clean install -Parq -Dtest=InboundCrashRecoveryTests#testCrashCommit {code} > XTS txbridge does not run commit when succesfully prepared on crash recovery > ---------------------------------------------------------------------------- > > Key: JBTM-3138 > URL: https://issues.jboss.org/browse/JBTM-3138 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > Attachments: server.log, stacktrace.txt > > > As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant. > In scenario > * WS call to the WFLY server > * inbound bridge injects the JTA transactions as subordinate under the WS AT one > * prepare is called and the 2PC phase finishes > * commit phase starts and JVM crashes > * restart of WFLY server > * recovery is expected to commit the participants > the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed. > This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3138) XTS txbridge does not run commit when succesfully prepared on crash recovery

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3138?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka commented on JBTM-3138: ---------------------------------------- It seems the recovery calls {{commit}} but the {{coordinator}} on the {{Prepared}} command is {{null}} (https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WS-T/dev/src/com...). Because of that the rollback is sent (https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WS-T/dev/src/com...). It sounds that the {{Coordinator}} instance is not activated for the durable participant (e.g. named as {{D0:ffff0a280527:4bf12fc8:5cbf1cd7:1d}}). The reason is under investigation. > XTS txbridge does not run commit when succesfully prepared on crash recovery > ---------------------------------------------------------------------------- > > Key: JBTM-3138 > URL: https://issues.jboss.org/browse/JBTM-3138 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > > As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant. > In scenario > * WS call to the WFLY server > * inbound bridge injects the JTA transactions as subordinate under the WS AT one > * prepare is called and the 2PC phase finishes > * commit phase starts and JVM crashes > * restart of WFLY server > * recovery is expected to commit the participants > the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed. > This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3138) XTS txbridge does not run commit when succesfully prepared on crash recovery

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3138?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3138: ----------------------------------- Summary: XTS txbridge does not run commit when succesfully prepared on crash recovery (was: XTS txbridge does not work to run commit for crash recovery) > XTS txbridge does not run commit when succesfully prepared on crash recovery > ---------------------------------------------------------------------------- > > Key: JBTM-3138 > URL: https://issues.jboss.org/browse/JBTM-3138 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > > As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant. > In scenario > * WS call to the WFLY server > * inbound bridge injects the JTA transactions as subordinate under the WS AT one > * prepare is called and the 2PC phase finishes > * commit phase starts and JVM crashes > * restart of WFLY server > * recovery is expected to commit the participants > the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed. > This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3138) XTS txbridge does not work to run commit for crash recovery

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3138?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3138: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1391 > XTS txbridge does not work to run commit for crash recovery > ----------------------------------------------------------- > > Key: JBTM-3138 > URL: https://issues.jboss.org/browse/JBTM-3138 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > > As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant. > In scenario > * WS call to the WFLY server > * inbound bridge injects the JTA transactions as subordinate under the WS AT one > * prepare is called and the 2PC phase finishes > * commit phase starts and JVM crashes > * restart of WFLY server > * recovery is expected to commit the participants > the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed. > This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3138) XTS txbridge does not work to run commit for crash recovery

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3138: -------------------------------------- Summary: XTS txbridge does not work to run commit for crash recovery Key: JBTM-3138 URL: https://issues.jboss.org/browse/JBTM-3138 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Affects Versions: 5.9.5.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant. In scenario * WS call to the WFLY server * inbound bridge injects the JTA transactions as subordinate under the WS AT one * prepare is called and the 2PC phase finishes * commit phase starts and JVM crashes * restart of WFLY server * recovery is expected to commit the participants the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed. This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3079) InboundBridge recovery aborts live transactions

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3079: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > InboundBridge recovery aborts live transactions > ----------------------------------------------- > > Key: JBTM-3079 > URL: https://issues.jboss.org/browse/JBTM-3079 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.32.Final, 5.9.0.Final > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.9.2.Final, 5.5.34.Final > > Attachments: jbtm3079.patch > > > During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes. > TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) > TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > > ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException > It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3079) InboundBridge recovery aborts live transactions

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3079: ----------------------------------- Status: Pull Request Sent (was: Reopened) > InboundBridge recovery aborts live transactions > ----------------------------------------------- > > Key: JBTM-3079 > URL: https://issues.jboss.org/browse/JBTM-3079 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.32.Final, 5.9.0.Final > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.5.34.Final, 5.9.2.Final > > Attachments: jbtm3079.patch > > > During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes. > TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) > TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > > ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException > It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3079) InboundBridge recovery aborts live transactions

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka closed JBTM-3079. ---------------------------------- > InboundBridge recovery aborts live transactions > ----------------------------------------------- > > Key: JBTM-3079 > URL: https://issues.jboss.org/browse/JBTM-3079 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.32.Final, 5.9.0.Final > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.5.34.Final, 5.9.2.Final > > Attachments: jbtm3079.patch > > > During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes. > TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) > TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > > ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException > It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3079) InboundBridge recovery aborts live transactions

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3079: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1387 > InboundBridge recovery aborts live transactions > ----------------------------------------------- > > Key: JBTM-3079 > URL: https://issues.jboss.org/browse/JBTM-3079 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.32.Final, 5.9.0.Final > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.5.34.Final, 5.9.2.Final > > Attachments: jbtm3079.patch > > > During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes. > TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) > TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > > ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException > It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3079) InboundBridge recovery aborts live transactions

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka reopened JBTM-3079: ------------------------------------ Assignee: Ondrej Chaloupka (was: Thomas Jenkinson) > InboundBridge recovery aborts live transactions > ----------------------------------------------- > > Key: JBTM-3079 > URL: https://issues.jboss.org/browse/JBTM-3079 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.32.Final, 5.9.0.Final > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.5.34.Final, 5.9.2.Final > > Attachments: jbtm3079.patch > > > During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes. > TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) > TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > > ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException > It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 7 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 April 2019