July 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3342) LRA annotated method should expose the parent context header

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3342: -------------------------------------- Summary: LRA annotated method should expose the parent context header Key: JBTM-3342 URL: https://issues.redhat.com/browse/JBTM-3342 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.5.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next When a method annotated with @LRA is invoked with a nested context the parent context should be made available to the invoked method via the [LRA_HTTP_ENDED_CONTEXT_HEADER|http://example.com]_] http header. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3341) Failed LRA is not kept in FailedTo* state in the object store

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3341?page=com.atlassian.jira.plugin... ] Martin Stefanko updated JBTM-3341: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1644 > Failed LRA is not kept in FailedTo* state in the object store > ------------------------------------------------------------- > > Key: JBTM-3341 > URL: https://issues.redhat.com/browse/JBTM-3341 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > when executing {{TckContextTests#testStatus,TckContextTests#testForget}} one after another the LRA started in testForget is kept in Closing state in object store even when it's removed from the in memory LRA lists. When the testStatus invokes recovery this LRA is also recovered (because it's still in Closing state) and then it's kept even in the in memory recovery list and again displayed to users. The testForget LRA is finished with failing participant (returning FailedToComplete) and the second phase correctly returns FINISH_ERROR, however, this change needs to be also reflected in the state of the parent Transaction object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3341) Failed LRA is not kept in FailedTo* state in the object store

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3341?page=com.atlassian.jira.plugin... ] Martin Stefanko updated JBTM-3341: ---------------------------------- Summary: Failed LRA is not kept in FailedTo* state in the object store (was: Failed participant should mark the enclosed LRA as failed) > Failed LRA is not kept in FailedTo* state in the object store > ------------------------------------------------------------- > > Key: JBTM-3341 > URL: https://issues.redhat.com/browse/JBTM-3341 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > when executing {{TckContextTests#testStatus,TckContextTests#testForget}} one after another the LRA started in testForget is kept in Closing state in object store even when it's removed from the in memory LRA lists. When the testStatus invokes recovery this LRA is also recovered (because it's still in Closing state) and then it's kept even in the in memory recovery list and again displayed to users. The testForget LRA is finished with failing participant (returning FailedToComplete) and the second phase correctly returns FINISH_ERROR, however, this change needs to be also reflected in the state of the parent Transaction object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3338) CMR getters should be thread safe and can't require JVM halt for appying configuration changes in JTAEnvironementBean

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3338?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3338: ----------------------------------- Summary: CMR getters should be thread safe and can't require JVM halt for appying configuration changes in JTAEnvironementBean (was: CMR getters should use copy-constructors in JTAEnvironementBean to ensure thread safety) > CMR getters should be thread safe and can't require JVM halt for appying configuration changes in JTAEnvironementBean > --------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3338 > URL: https://issues.redhat.com/browse/JBTM-3338 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The CMR getters should use the copy constructors as it's usual in other places in JTAEnvironemtBean. The copy constructor helps the thread safety. > * https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... > * https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... > * https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3338) CMR getters should be thread safe and can't require JVM halt for applying configuration changes in JTAEnvironementBean

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3338?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3338: ----------------------------------- Summary: CMR getters should be thread safe and can't require JVM halt for applying configuration changes in JTAEnvironementBean (was: CMR getters should be thread safe and can't require JVM halt for appying configuration changes in JTAEnvironementBean) > CMR getters should be thread safe and can't require JVM halt for applying configuration changes in JTAEnvironementBean > ---------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3338 > URL: https://issues.redhat.com/browse/JBTM-3338 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The CMR getters should use the copy constructors as it's usual in other places in JTAEnvironemtBean. The copy constructor helps the thread safety. > * https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... > * https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... > * https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaJTA/jta/class... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3341) Failed participant should mark the enclosed LRA as failed

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3341: ------------------------------------- Summary: Failed participant should mark the enclosed LRA as failed Key: JBTM-3341 URL: https://issues.redhat.com/browse/JBTM-3341 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.4.Final Reporter: Martin Stefanko Assignee: Martin Stefanko when executing {{TckContextTests#testStatus,TckContextTests#testForget}} one after another the LRA started in testForget is kept in Closing state in object store even when it's removed from the in memory LRA lists. When the testStatus invokes recovery this LRA is also recovered (because it's still in Closing state) and then it's kept even in the in memory recovery list and again displayed to users. The testForget LRA is finished with failing participant (returning FailedToComplete) and the second phase correctly returns FINISH_ERROR, however, this change needs to be also reflected in the state of the parent Transaction object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3308) Some TCK tests pass but leave the LRAs in not finished state

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3308?page=com.atlassian.jira.plugin... ] Martin Stefanko edited comment on JBTM-3308 at 7/1/20 7:34 AM: --------------------------------------------------------------- I don't see the way how to link different JBTMs. I will keep the list of forked issues in this comment: * https://issues.redhat.com/browse/JBTM-3312 * https://issues.redhat.com/browse/JBTM-3320 * https://issues.redhat.com/browse/JBTM-3326 * https://issues.redhat.com/browse/JBTM-3341 was (Author: mstefank): I don't see the way how to link different JBTMs. I will keep the list of forked issues in this comment: * https://issues.redhat.com/browse/JBTM-3312 * https://issues.redhat.com/browse/JBTM-3320 * https://issues.redhat.com/browse/JBTM-3326 > Some TCK tests pass but leave the LRAs in not finished state > ------------------------------------------------------------ > > Key: JBTM-3308 > URL: https://issues.redhat.com/browse/JBTM-3308 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > It seems that the LRA is correctly closed but the /lra-coordinator still reports it in Active status. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 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 Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3331?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on JBTM-3331 at 7/1/20 7:05 AM: ---------------------------------------------------------------- This report is not about the TCK test failure and it's not meant to fix the TCK instability by changing the implementation. The reference to the TCK tests only provides the context for when the behaviour can be observed. When the situation which was causing the TCK failures happen then Narayana does not behave in the deterministic and correct(...?) way. The scenario is: * client calls to the {{@LRA}} method (the participant) * the filter causes the LRA is started * LRA defines short timeout and the LRA is timeouted * the filter tries to enlist the participant to LRA. As the LRA was cancelled the enlistment fails. Now the follow up code call goes to the method {{NarayanaLRAClient#endLRA}}. It's because the filter comes there was some failure and thus it tries to end (cancel) it. The result of the {{endLRA}} method influences the return/error code that the client receives (aka. client called the `@LRA` method and now it's still waiting for the response from that call at this point). If the coordinator already lost the notion about the LRA instance then the {{endLRA}} will return a different exception code and the filter processing returns to client {{412}} or {{500}}. First, the behaviour is quite variable while I think the client should be receiving only {{412}} in all cases. I'm not sure right now if the {{500}} is strictly against the spec but I think it is not correct for this scenario. was (Author: ochaloup): This report is not about the TCK test failure and it's not meant to fix the TCK instability by changing the implementation. The reference to the TCK tests only provides the context for when the behaviour can be observed. As said it's _the related behaviour of the Narayana implementation_. When the situation which was causing the TCK failures happen then Narayana does not behave in the deterministic and correct(...?) way. The scenario is: * client calls to the {{@LRA}} method (the participant) * the filter causes the LRA is started * LRA defines short timeout and the LRA is timeouted * the filter tries to enlist the participant to LRA. As the LRA was cancelled the enlistment fails. Now the follow up code call goes to the method {{NarayanaLRAClient#endLRA}}. It's because the filter comes there was some failure and thus it tries to end (cancel) it. The result of the {{endLRA}} method influences the return/error code that the client receives (aka. client called the `@LRA` method and now it's still waiting for the response from that call at this point). If the coordinator already lost the notion about the LRA instance then the {{endLRA}} will return a different exception code and the filter processing returns to client {{412}} or {{500}}. First, the behaviour is quite variable while I think the client should be receiving only {{412}} in all cases. I'm not sure right now if the {{500}} is strictly against the spec but I think it is not correct for this scenario. > 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 > > 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, 5 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 Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3331?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3331: ---------------------------------------- This report is not about the TCK test failure and it's not meant to fix the TCK instability by changing the implementation. The reference to the TCK tests only provides the context for when the behaviour can be observed. As said it's _the related behaviour of the Narayana implementation_. When the situation which was causing the TCK failures happen then Narayana does not behave in the deterministic and correct(?) way. The scenario is: * client calls to the {{@LRA}} method (the participant) * the filter causes the LRA is started * LRA defines short timeout and the LRA is timeouted * the filter tries to enlist the participant to LRA. As the LRA was cancelled the enlistment fails. Now the follow up code call goes to the method {{NarayanaLRAClient#endLRA}}. It's because the filter comes there was some failure and thus it tries to end (cancel) it. The result of the {{endLRA}} method influences the return/error code that the client receives (aka. client called the `@LRA` method and now it's still waiting for the response from that call at this point). If the coordinator already lost the notion about the LRA instance then the {{endLRA}} will return a different exception code and the filter processing returns to client {{412}} or {{500}}. First, the behaviour is quite variable while I think the client should be receiving only {{412}} in all cases. I'm not sure right now if the {{500}} is strictly against the spec but I think it is not correct for this scenario. > 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 > > 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, 5 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 Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3331?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on JBTM-3331 at 7/1/20 7:00 AM: ---------------------------------------------------------------- This report is not about the TCK test failure and it's not meant to fix the TCK instability by changing the implementation. The reference to the TCK tests only provides the context for when the behaviour can be observed. As said it's _the related behaviour of the Narayana implementation_. When the situation which was causing the TCK failures happen then Narayana does not behave in the deterministic and correct(...?) way. The scenario is: * client calls to the {{@LRA}} method (the participant) * the filter causes the LRA is started * LRA defines short timeout and the LRA is timeouted * the filter tries to enlist the participant to LRA. As the LRA was cancelled the enlistment fails. Now the follow up code call goes to the method {{NarayanaLRAClient#endLRA}}. It's because the filter comes there was some failure and thus it tries to end (cancel) it. The result of the {{endLRA}} method influences the return/error code that the client receives (aka. client called the `@LRA` method and now it's still waiting for the response from that call at this point). If the coordinator already lost the notion about the LRA instance then the {{endLRA}} will return a different exception code and the filter processing returns to client {{412}} or {{500}}. First, the behaviour is quite variable while I think the client should be receiving only {{412}} in all cases. I'm not sure right now if the {{500}} is strictly against the spec but I think it is not correct for this scenario. was (Author: ochaloup): This report is not about the TCK test failure and it's not meant to fix the TCK instability by changing the implementation. The reference to the TCK tests only provides the context for when the behaviour can be observed. As said it's _the related behaviour of the Narayana implementation_. When the situation which was causing the TCK failures happen then Narayana does not behave in the deterministic and correct(?) way. The scenario is: * client calls to the {{@LRA}} method (the participant) * the filter causes the LRA is started * LRA defines short timeout and the LRA is timeouted * the filter tries to enlist the participant to LRA. As the LRA was cancelled the enlistment fails. Now the follow up code call goes to the method {{NarayanaLRAClient#endLRA}}. It's because the filter comes there was some failure and thus it tries to end (cancel) it. The result of the {{endLRA}} method influences the return/error code that the client receives (aka. client called the `@LRA` method and now it's still waiting for the response from that call at this point). If the coordinator already lost the notion about the LRA instance then the {{endLRA}} will return a different exception code and the filter processing returns to client {{412}} or {{500}}. First, the behaviour is quite variable while I think the client should be receiving only {{412}} in all cases. I'm not sure right now if the {{500}} is strictly against the spec but I think it is not correct for this scenario. > 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 > > 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, 5 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