November 2018 - jbossts-issues - Jboss List Archives

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

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3080?page=com.atlassian.jira.plugin.... ] Tom Jenkinson deleted JBTM-3080: -------------------------------- > InboundBridge recovery aborts live transactions > ----------------------------------------------- > > Key: JBTM-3080 > URL: https://issues.jboss.org/browse/JBTM-3080 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Tom Jenkinson > Priority: Critical > > 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)

6 years

1
0
0 / 0

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

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Work on JBTM-3079 started by Tom 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: Tom Jenkinson > Priority: Critical > 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)

6 years

1
0
0 / 0

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

by Tom Jenkinson (Jira)

Tom Jenkinson created JBTM-3080: ----------------------------------- Summary: InboundBridge recovery aborts live transactions Key: JBTM-3080 URL: https://issues.jboss.org/browse/JBTM-3080 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: Tom Jenkinson 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)

6 years

1
0
0 / 0

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

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3079: ---------------------------------- Affects Version/s: 5.9.0.Final > 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: Ondra Chaloupka > Priority: Critical > 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)

6 years

1
0
0 / 0

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

by Jonathan Halliday (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Jonathan Halliday updated JBTM-3079: ------------------------------------ Attachment: jbtm3079.patch > 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 > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Ondra Chaloupka > Priority: Critical > 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)

6 years

1
0
0 / 0

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

by Jonathan Halliday (Jira)

Jonathan Halliday created JBTM-3079: --------------------------------------- Summary: 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 Environment: EAP 7.1.5 / 5.5.32.Final Reporter: Jonathan Halliday Assignee: Ondra Chaloupka 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)

6 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3061) CMR recovery wrongly handles commit and rollback

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3061?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3061: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.5.next Resolution: Done > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3061 > URL: https://issues.jboss.org/browse/JBTM-3061 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.32.Final > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > Priority: Major > Fix For: 5.5.next > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3018) Migrate the LRA implementation to use the microprofile-lra API

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3018?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1385 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Migrate the LRA implementation to use the microprofile-lra API > -------------------------------------------------------------- > > Key: JBTM-3018 > URL: https://issues.jboss.org/browse/JBTM-3018 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.8.2.Final > > > The LRA implementation should depend on the Eclipse microprofile-lra maven artifact for the API (https://github.com/jbosstm/microprofile-lra/tree/microprofile-lra/api). > Make sure the API bundled with narayana is deprecated. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3018) Migrate the LRA implementation to use the microprofile-lra API

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3018?page=com.atlassian.jira.plugin.... ] Michael Musgrove reopened JBTM-3018: ------------------------------------ Reopened since there are sill some deprecated LRA API classes in the code base > Migrate the LRA implementation to use the microprofile-lra API > -------------------------------------------------------------- > > Key: JBTM-3018 > URL: https://issues.jboss.org/browse/JBTM-3018 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.8.2.Final > > > The LRA implementation should depend on the Eclipse microprofile-lra maven artifact for the API (https://github.com/jbosstm/microprofile-lra/tree/microprofile-lra/api). > Make sure the API bundled with narayana is deprecated. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3076) Upgrade the arquillian core and wildfly-arquillian-container

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3076?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3076: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade the arquillian core and wildfly-arquillian-container > ------------------------------------------------------------ > > Key: JBTM-3076 > URL: https://issues.jboss.org/browse/JBTM-3076 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Major > Fix For: 5.next > > > The RTS AS integration failed and these two artifacts need to be upgraded. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2018