July 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3329) Add supportNested alternative for LRA methods

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3329?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3329: ----------------------------------- Fix Version/s: 5.next > Add supportNested alternative for LRA methods > --------------------------------------------- > > Key: JBTM-3329 > URL: https://issues.redhat.com/browse/JBTM-3329 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > Add something similar to @LRA(supportNested=false) for LRA participant to test out the inclusion of this API in the specification. Possibly something like new annotation @TopLevelLRAParticipant that can be placed on LRA participant class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3330) Nested closed LRA is kept in Closing state which is breaking the LRA state model

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3330?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3330: ----------------------------------- Fix Version/s: 5.next > Nested closed LRA is kept in Closing state which is breaking the LRA state model > -------------------------------------------------------------------------------- > > Key: JBTM-3330 > URL: https://issues.redhat.com/browse/JBTM-3330 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Priority: Major > Fix For: 5.next > > > The closed nested LRA is kept in the Closing state until the parent closes/cancels. This is against the the LRA state model - https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asc... where only transition from Closed to Cancelling is allowed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3344) Remove Thorntail as LRA runtime

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3344?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3344: ----------------------------------- Fix Version/s: 5.next > Remove Thorntail as LRA runtime > ------------------------------- > > Key: JBTM-3344 > URL: https://issues.redhat.com/browse/JBTM-3344 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > The LRA provides the runner for Thorntail runtime. The Thorntail is being abandoned for Quarkus. > The LRA may stop to provide the Thorntail runner and it could stop to use it in tests. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3309) Investigate using MicroProfile JSON Web Token to secure interaction with an LRA coordinator

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3309?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3309: ----------------------------------- Fix Version/s: 5.next > Investigate using MicroProfile JSON Web Token to secure interaction with an LRA coordinator > ------------------------------------------------------------------------------------------- > > Key: JBTM-3309 > URL: https://issues.redhat.com/browse/JBTM-3309 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Critical > Fix For: 5.next > > > The Narayana implementation of the MicroProfile LRA specification uses a JAX-RS filter to communicate with a remote coordinator. The interaction is currently insecure. This issue is to investigate the best way of securing this channel. Since the JAX-RS filter is applied to the MicroProfile service we should initially investigate the MicroProfile security solution (MicroProfile JSON Web Token). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3331) LRA end should not return internal server error when precondition fails as it's considered behaviour by spec

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3331?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3331: ----------------------------------- Fix Version/s: 5.next > LRA end should not return internal server error when precondition fails as it's considered behaviour by spec > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3331 > URL: https://issues.redhat.com/browse/JBTM-3331 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.next > > > I've spent some time with https://issues.redhat.com/browse/JBTM-3318 recently and I have a doubt about behaviour of the LRA. The JBTM-3318 consists of race condition on starting/enlisting/timeouting the LRA. > The same issue makes failing the `TckTests#timeLimit` and `TckRecoveryTests#testCancelWhenParticipantIsUnavailable` on our slow AMS CI. > I don't want to talk now about the TCK failure but about the related behaviour of the Narayana implementation. > The LRA participant defines the {{timeLimit}} (https://github.com/eclipse/microprofile-lra/blob/1.0-M1/tck/src/main/java...). > And what happens is that the client (TCK test) calls the LRA method, the JAX-RS filter starts a LRA on coordinator, meanwhile the timeout limit elapses, the JAX-RS filter tries to enlist the LRA participant to started LRA but it fails as the LRA was cancelled because of timeout. > Now. The possible non-deterministic Narayana behaviour is that in case of failure on LRA participant enlistment the client may or may not get internal server error. > It's because the LRA in timeouted state on client is tried to be cancelled (see https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-client/...). > The {{NarayanaLRAClient#endLRA}} tries to cancel the LRA. But as the coordinator timeouted the LRA then now depends if recovery already removed the LRA or not. If the LRA was not removed yet then {{412, PRECONDITION FAILED}} is returned. If the recovery made it then {{404, NOT FOUDN}} is returned. > Now the {{endLRA}} considers the {{404}} as not a failure that is considered as {{500, INTERNAL SERVER ERROR}} while the {{412, PRECONDITION FAILED}} is considered as internal server error. That should not be that way as the LRA spec considers {{412}} as "correct" error (see https://github.com/eclipse/microprofile-lra/blob/1.0-M1/api/src/main/java...). > Such an anticipated return state should not be reported to client as {{500}} - {{internal server error}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[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 > 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 > Priority: Blocker > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3343) Integration LRA tests need to be runnable on all runtimes

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3343?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3343: ----------------------------------- Fix Version/s: 5.next > Integration LRA tests need to be runnable on all runtimes > --------------------------------------------------------- > > Key: JBTM-3343 > URL: https://issues.redhat.com/browse/JBTM-3343 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.next > > > The LRA integration testing is currently split to two parts. The Narayana byteman recovery testing is run only with WildFly runtime while the TCK and other integration tests are run with combination of Qurakus/Thorntail. > The goal of this issue is to change the structure of the LRA integration tests to run with all available runtimes. Currently we have Quarkus, WildFly and Thorntail. > The integration tests need be runnable against the all runtimes. > NOTE: The Thorntail is eprecated and will be removed from the LRA. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[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 reassigned JBTM-3223: -------------------------------------- Assignee: (was: Michael Musgrove) > 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 > Priority: Blocker > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3245) Check the behaviour when LRA enlistment fails due to coordinator unavailability

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3245?page=com.atlassian.jira.plugin... ] Michael Musgrove reassigned JBTM-3245: -------------------------------------- Assignee: (was: Michael Musgrove) > Check the behaviour when LRA enlistment fails due to coordinator unavailability > ------------------------------------------------------------------------------- > > Key: JBTM-3245 > URL: https://issues.redhat.com/browse/JBTM-3245 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > There is no test that verifies an LRA is cancelled if a participant tries to join with an LRA and fails because an external coordinator is unavailable. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3245) Check the behaviour when LRA enlistment fails due to coordinator unavailability

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3245?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3245: ----------------------------------- Fix Version/s: 5.next > Check the behaviour when LRA enlistment fails due to coordinator unavailability > ------------------------------------------------------------------------------- > > Key: JBTM-3245 > URL: https://issues.redhat.com/browse/JBTM-3245 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > There is no test that verifies an LRA is cancelled if a participant tries to join with an LRA and fails because an external coordinator is unavailable. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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