January 2020 - jbossts-issues - Jboss List Archives

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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on JBTM-3239 at 1/6/20 3:59 AM: ---------------------------------------------------------------- The participant is {{Completed/Compensated}} when the HTTP REST call, to the appropriate participant's method, finishes with success. The {{AfterLRA}} is only an additional announcement that informs how the whole(!) LRA finished. In other words the {{AfterLRA}} does not influence the final state of the participant. What is meant by the "forget"? It could be I missed something but the participant may define a method annotated with {{@Forget}} which could be invoked by coordinator to inform the participant that there is no more need to retain information about the particular LRA. This forget call is connected to the transaction management of the participant. The {{AfterLRA}} is an additional information on top of it. For the LRA transaction would be safe as whole then even the participant has to provide some "guarantee" defined in the LRA protocol. This guarantee means that the participant needs to retain and persist some information until it's said by coordinator that the participant has free to remove it. >From the spec (and my understanding) the {{@Forget}} is usable only when nested transaction (nested LRA) is in use. Then the coordinator may call e.g. {{@Complete}} on participant but there is still some chance thatn {{@Compensate}} will be called on the same LRA id. The participant has to persist this until the {{@Forget}} is invoked. Now the {{AfterLRA}} does not requires such "guarantee". It's up to the participant if it knows what to do with the {{AfterLRA}} call or if such information is just left unused. In other words the {{Forget}} and {{AfterLRA}} have not connection. The participant is not forced to retain/persist any information for {{AfterLRA}} working properly and safely. was (Author: ochaloup): The participant is {{Completed/Compensated}} when the HTTP REST call, to the appropriate participant's method, finishes with success. The {{AfterLRA}} is an announcement how the whole LRA finished. In other words the {{AfterLRA}} does not influence the final state of the participant. What is meant by the "forget"? It could be I missed something but the participant may define a method annotated with {{@Forget}} which could be invoked by coordinator to inform the participant that there is no more need to retain information about the particular LRA. This forget call is connected to the transaction management of the participant. The {{AfterLRA}} is an additional information on top of it. For the LRA transaction would be safe as whole then even the participant has to provide some "guarantee" defined in the LRA protocol. This guarantee means that the participant needs to retain and persist some information until it's said by coordinator that the participant has free to remove it. >From the spec (and my understanding) the {{@Forget}} is usable only when nested transaction (nested LRA) is in use. Then the coordinator may call e.g. {{@Complete}} on participant but there is still some chance thatn {{@Compensate}} will be called on the same LRA id. The participant has to persist this until the {{@Forget}} is invoked. Now the {{AfterLRA}} does not requires such "guarantee". It's up to the participant if it knows what to do with the {{AfterLRA}} call or if such information is just left unused. In other words the {{Forget}} and {{AfterLRA}} have not connection. The participant is not forced to retain/persist any information for {{AfterLRA}} working properly and safely. > Failing AfterLRA participant calls are not repeated > --------------------------------------------------- > > 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 > -- 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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3239: ---------------------------------------- The participant is {{Completed/Compensated}} when the HTTP REST call, to the appropriate participant's method, finishes with success. The {{AfterLRA}} is an announcement how the whole LRA finished. In other words the {{AfterLRA}} does not influence the final state of the participant. What is meant by the "forget"? It could be I missed something but the participant may define a method annotated with {{@Forget}} which could be invoked by coordinator to inform the participant that there is no more need to retain information about the particular LRA. This forget call is connected to the transaction management of the participant. The {{AfterLRA}} is an additional information on top of it. For the LRA transaction would be safe as whole then even the participant has to provide some "guarantee" defined in the LRA protocol. This guarantee means that the participant needs to retain and persist some information until it's said by coordinator that the participant has free to remove it. >From the spec (and my understanding) the {{@Forget}} is usable only when nested transaction (nested LRA) is in use. Then the coordinator may call e.g. {{@Complete}} on participant but there is still some chance thatn {{@Compensate}} will be called on the same LRA id. The participant has to persist this until the {{@Forget}} is invoked. Now the {{AfterLRA}} does not requires such "guarantee". It's up to the participant if it knows what to do with the {{AfterLRA}} call or if such information is just left unused. In other words the {{Forget}} and {{AfterLRA}} have not connection. The participant is not forced to retain/persist any information for {{AfterLRA}} working properly and safely. > Failing AfterLRA participant calls are not repeated > --------------------------------------------------- > > 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 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3240) Rename LRARecord#getRecoveryCoordinatorURI to LRARecord#getRecoveryURI

by Anonymous (Jira)

[ https://issues.redhat.com/browse/JBTM-3240?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Martin Stefanko created pull request #1543 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Rename LRARecord#getRecoveryCoordinatorURI to LRARecord#getRecoveryURI > ---------------------------------------------------------------------- > > Key: JBTM-3240 > URL: https://issues.redhat.com/browse/JBTM-3240 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > LRARecord#getRecoveryCoordinatorURI is misleading as the actual returned value is a `recoveryURI` in which the recovery coordinator is included but it is not it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3240) Rename LRARecord#getRecoveryCoordinatorURI to LRARecord#getRecoveryURI

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3240: ------------------------------------- Summary: Rename LRARecord#getRecoveryCoordinatorURI to LRARecord#getRecoveryURI Key: JBTM-3240 URL: https://issues.redhat.com/browse/JBTM-3240 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.1.Final Reporter: Martin Stefanko Assignee: Martin Stefanko LRARecord#getRecoveryCoordinatorURI is misleading as the actual returned value is a `recoveryURI` in which the recovery coordinator is included but it is not it. -- 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

by Anonymous (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Martin Stefanko created pull request #1542 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Failing AfterLRA participant calls are not repeated > --------------------------------------------------- > > 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 > -- 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

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Martin Stefanko commented on JBTM-3239: --------------------------------------- I would propose to move the afterLRA handling solely to the LRARecord. However, there are a few questions on how to handle it: * is the participant in the status Completed/Compensated when the Complete/Compensate returns a successful response but there is an AfterLRA method? In other words, when is the participant truly Completed/Compensated? Is it including a successful AfterLRA call? * because of https://issues.redhat.com/browse/JBTM-3228 I think the best solution would be to add a boolean field stating whether afterLRA should be called and/or forget should be called. As both of these methods will be called after the participant "ends" (Complete/Compensate returns a successful response) * Please note that we will then be returning HEURISTIC_HAZARD for unsuccessful afterLRA (and forget) calls so we need to make sure that these methods are handled before the execution continues to the actual logic handling this H_H in Completing/Compensating states. [~mmusgrov], [~tomjenkinson], [~ochaloup] > Failing AfterLRA participant calls are not repeated > --------------------------------------------------- > > 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 > -- 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

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3239: ------------------------------------- Summary: Failing AfterLRA participant calls are not repeated 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 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3232) Conflicting JAX-RS paths in io.narayana.lra.coordinator.api.Coordinator

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3232?page=com.atlassian.jira.plugin... ] Michael Musgrove resolved JBTM-3232. ------------------------------------ Resolution: Done > Conflicting JAX-RS paths in io.narayana.lra.coordinator.api.Coordinator > ----------------------------------------------------------------------- > > Key: JBTM-3232 > URL: https://issues.redhat.com/browse/JBTM-3232 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > In the JAX-RS resource io.narayana.lra.coordinator.api.Coordinator there are two conflicting JAX-RS paths: > {code:java} > @GET > @Path("{LraId}/status") > public Response getLRAStatus > {code} > and > {code:java} > @GET > @Path("{NestedLraId}/status") > public Response getNestedLRAStatus > {code} > which impose erroneous states for the nested LRAs. I would propose to prefix all endpoints for nested LRAs at the Coordinator class to be prefixed with `/nested`. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3232) Conflicting JAX-RS paths in io.narayana.lra.coordinator.api.Coordinator

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3232?page=com.atlassian.jira.plugin... ] Michael Musgrove reopened JBTM-3232: ------------------------------------ The issue may only be resolved when the LRA branch is merged onto master. > Conflicting JAX-RS paths in io.narayana.lra.coordinator.api.Coordinator > ----------------------------------------------------------------------- > > Key: JBTM-3232 > URL: https://issues.redhat.com/browse/JBTM-3232 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > In the JAX-RS resource io.narayana.lra.coordinator.api.Coordinator there are two conflicting JAX-RS paths: > {code:java} > @GET > @Path("{LraId}/status") > public Response getLRAStatus > {code} > and > {code:java} > @GET > @Path("{NestedLraId}/status") > public Response getNestedLRAStatus > {code} > which impose erroneous states for the nested LRAs. I would propose to prefix all endpoints for nested LRAs at the Coordinator class to be prefixed with `/nested`. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3232) Conflicting JAX-RS paths in io.narayana.lra.coordinator.api.Coordinator

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3232?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3232: ----------------------------------- Comment: was deleted (was: The issue may only be resolved when the LRA branch is merged onto master.) > Conflicting JAX-RS paths in io.narayana.lra.coordinator.api.Coordinator > ----------------------------------------------------------------------- > > Key: JBTM-3232 > URL: https://issues.redhat.com/browse/JBTM-3232 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > In the JAX-RS resource io.narayana.lra.coordinator.api.Coordinator there are two conflicting JAX-RS paths: > {code:java} > @GET > @Path("{LraId}/status") > public Response getLRAStatus > {code} > and > {code:java} > @GET > @Path("{NestedLraId}/status") > public Response getNestedLRAStatus > {code} > which impose erroneous states for the nested LRAs. I would propose to prefix all endpoints for nested LRAs at the Coordinator class to be prefixed with `/nested`. -- 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