August 2016 - jbossts-issues - Jboss List Archives

[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: ------------------------------------- Please can you provide a link in the reproducer to the repo where the test is? > 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)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2739) Add a CI job for testing jboss-transaction-spi

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2739: -------------------------------------- Summary: Add a CI job for testing jboss-transaction-spi Key: JBTM-2739 URL: https://issues.jboss.org/browse/JBTM-2739 Project: JBoss Transaction Manager Issue Type: Task Components: SPI Affects Versions: 5.3.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next We need a CI job to test that narayana works with the latest jboss-transaction-spi and this should include PRs as well as master. In addition, the two projects duplicate tests so the the duplicates need removing from narayana (but only after we have added this CI testing). Note that jboss-transaction-spi has a test dependency on the last released stable version of narayana so that dependency would need to changed to the version of our current SNAPSHOT for these new proposed CI jobs to be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2738) Upgrade jboss-transaction-spi dependency to 7.3.3.Final

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2738: -------------------------------------- Summary: Upgrade jboss-transaction-spi dependency to 7.3.3.Final Key: JBTM-2738 URL: https://issues.jboss.org/browse/JBTM-2738 Project: JBoss Transaction Manager Issue Type: Task Components: SPI Affects Versions: 5.3.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 5.next There is a new version of the jboss-transaction-spi which fixed a UserTransaction serialization issue. This change should not affect narayana (hence the minor priority leve) but we should be consuming the most recent release. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 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 updated JBTM-2735: -------------------------------- Priority: Critical (was: Major) > 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)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2734: -------------------------------- Fix Version/s: 5.next > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2734: -------------------------------- Priority: Critical (was: Minor) > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 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 updated JBTM-2735: -------------------------------- Fix Version/s: 5.next > 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)

9 years, 7 months

1
0
0 / 0

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

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2671?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Gytis Trikleris created pull request #174 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > 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)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2669) Refactor "impl" package in compensations module to "internal"

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2669?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Gytis Trikleris created pull request #50 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Refactor "impl" package in compensations module to "internal" > ------------------------------------------------------------- > > Key: JBTM-2669 > URL: https://issues.jboss.org/browse/JBTM-2669 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2726) Replace deprecated OutputCapture in Spring Boot quickstart test

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2726?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2726: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Replace deprecated OutputCapture in Spring Boot quickstart test > --------------------------------------------------------------- > > Key: JBTM-2726 > URL: https://issues.jboss.org/browse/JBTM-2726 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Replace deprecated org.springframework.boot.test.OutputCapture with org.springframework.boot.test.rule.OutputCapture. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2016