January 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3223) Validate LRA behaviour when multiple LRA's are active on the same thread

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3223?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3223: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Validate LRA behaviour when multiple LRA's are active on the same thread > ------------------------------------------------------------------------- > > Key: JBTM-3223 > URL: https://issues.redhat.com/browse/JBTM-3223 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Add tests that check that when multiple LRA's are active on the same thread that as one LRA finishes that: > - the next one is handled correctly > - creating another one still works fine > This issues relates to some suspect code at the end of the method `NarayanaLRAClient#endLRA` where the base URI of the target coordinator includes the Uid part of the LRA id. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3225) Decide whether we should make the internal LRA client API not auto closable

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3225?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3225: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > Decide whether we should make the internal LRA client API not auto closable > --------------------------------------------------------------------------- > > Key: JBTM-3225 > URL: https://issues.redhat.com/browse/JBTM-3225 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA implementation contains an internal client API called io.narayana.lra.client.NarayanaLRAClient which implements java.io.Closeable. A recent PR (see issue https://issues.jboss.org/browse/JBTM-3212) made the implementation of the close method a NOOP (since there is no longer any need for cleanup actions). But the method was left empty since there is a possibility that is will be needed in LRA version 1.x where a LRA client API will be added and since there are existing users of the client API. > This task is a reminder to revisit the decision to remove java.io.Closeable prior to releasing an implementation of [version 1.0 of the LRA specification|https://github.com/eclipse/microprofile-lra/issues?q=is%3Ao...]. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3231) LRA recovery test fails after restart on JDK11

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3231?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3231: ----------------------------------- Fix Version/s: 5.next (was: 5.10.2.Final) > LRA recovery test fails after restart on JDK11 > ---------------------------------------------- > > Key: JBTM-3231 > URL: https://issues.redhat.com/browse/JBTM-3231 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, Testing > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > CI testing: > LRACoordinatorTestCase=testRecovery2 fails to restart the container after crashing via byteman on JDK11. Seems to be intermittent on Amsterdam CI and more consistent on Upshift, for example: > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/552/ > https://ci-master-jenkins-csb-narayana.cloud.paas.psi.redhat.com/job/nara... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3231) LRA recovery test fails after restart on JDK11

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3231?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Michael Musgrove created pull request #1550 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA recovery test fails after restart on JDK11 > ---------------------------------------------- > > Key: JBTM-3231 > URL: https://issues.redhat.com/browse/JBTM-3231 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, Testing > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > CI testing: > LRACoordinatorTestCase=testRecovery2 fails to restart the container after crashing via byteman on JDK11. Seems to be intermittent on Amsterdam CI and more consistent on Upshift, for example: > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/552/ > https://ci-master-jenkins-csb-narayana.cloud.paas.psi.redhat.com/job/nara... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3238) Coordinator#completeNestedLRA and Coordinator#compensateNestedLRA should return ParticipantStatus

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3238?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3238: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Coordinator#completeNestedLRA and Coordinator#compensateNestedLRA should return ParticipantStatus > ------------------------------------------------------------------------------------------------- > > Key: JBTM-3238 > URL: https://issues.redhat.com/browse/JBTM-3238 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > This is a follow up on https://issues.redhat.com/browse/JBTM-3234 where I missed two other methods that represent complete and compensate which should also return ParticipantStatus. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3229) Allow to enlist AfterLRA listeners after the LRA enters the ending phase

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3229?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3229: ---------------------------------------- Not yet because the fix contains a bug which means that a participant is allowed to enlist with an inactive LRA (cancelling or closing) and this breaks our state model. I raised https://github.com/jbosstm/narayana/pull/1549 for the fix > Allow to enlist AfterLRA listeners after the LRA enters the ending phase > ------------------------------------------------------------------------ > > Key: JBTM-3229 > URL: https://issues.redhat.com/browse/JBTM-3229 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > https://github.com/eclipse/microprofile-lra/issues/241 > The specification was updated to allow AfterLRA listeners (LRA resources without Compensate method but with the AfterLRA method) to enlist for AfterLRA notification even after the LRA enters the ending (closing/canceling) phase. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3229) Allow to enlist AfterLRA listeners after the LRA enters the ending phase

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3229?page=com.atlassian.jira.plugin... ] Martin Stefanko commented on JBTM-3229: --------------------------------------- it's up to [~mmusgrov]. We soon will be ready for another RC in the spec I believe. > Allow to enlist AfterLRA listeners after the LRA enters the ending phase > ------------------------------------------------------------------------ > > Key: JBTM-3229 > URL: https://issues.redhat.com/browse/JBTM-3229 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > https://github.com/eclipse/microprofile-lra/issues/241 > The specification was updated to allow AfterLRA listeners (LRA resources without Compensate method but with the AfterLRA method) to enlist for AfterLRA notification even after the LRA enters the ending (closing/canceling) phase. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3239) Failing AfterLRA participant calls are not repeated with recovery module

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Martin Stefanko updated JBTM-3239: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1548 > Failing AfterLRA participant calls are not repeated with recovery module > ------------------------------------------------------------------------ > > Key: JBTM-3239 > URL: https://issues.redhat.com/browse/JBTM-3239 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The afterLRA calls are currently delivered only twice when the LRA is finished (twice because of JBTM-3163). When these two calls fail the afterLRA call is never repeated again. However, the specification states that afterLRA must be repeated until the 200 status code is returned. > The main reason for this issue is the handling of afterLRA listeners in the Transaction object which means that the LRA enters the end phase (Closed/Cancelled) then the afterLRA listeners are called (twice because of above-mentioned issue) but if these calls fail there is nothing telling the transaction object to repeat the calls on the recovery. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3221) Refactor NarayanaLRARecovery according to the specification upgrades

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3221?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3221: ---------------------------------------- I thought we were going for resolved but no fixversion once it made it to LRA branch? We could discuss on https://developer.jboss.org/en/jbosstm/dev/content?filterID=contentstatus... > Refactor NarayanaLRARecovery according to the specification upgrades > -------------------------------------------------------------------- > > Key: JBTM-3221 > URL: https://issues.redhat.com/browse/JBTM-3221 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > Refactor the NarayanaLRARecovery according to the spec changes in [LRA issue 249|https://github.com/eclipse/microprofile-lra/issues/249]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3229) Allow to enlist AfterLRA listeners after the LRA enters the ending phase

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3229?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3229: ---------------------------------------- Shouldn't this be marked resolved (without fix version though) as it is on LRA branch: https://github.com/jbosstm/narayana/commits/LRA > Allow to enlist AfterLRA listeners after the LRA enters the ending phase > ------------------------------------------------------------------------ > > Key: JBTM-3229 > URL: https://issues.redhat.com/browse/JBTM-3229 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > https://github.com/eclipse/microprofile-lra/issues/241 > The specification was updated to allow AfterLRA listeners (LRA resources without Compensate method but with the AfterLRA method) to enlist for AfterLRA notification even after the LRA enters the ending (closing/canceling) phase. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 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 January 2020