January 2020 - jbossts-issues - Jboss List Archives

[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: ---------------------------------- Summary: Failing AfterLRA participant calls are not repeated with recovery module (was: Failing AfterLRA participant calls are not repeated) > 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 > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

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

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3239: ---------------------------------------- Thanks [~mstefank] one thing I was trying to get at was whether the context of the initial issue could be described in the description field as a statement rather than in the comments section? e.g. are they never repeated, or only repeated in certain conditions, does crash play a part? I couldn't spot FailingParticipantCallsIT#testFailingAfterLRA running on your [ PR | https://github.com/jbosstm/narayana/pull/1542 ] but I think that might be because the TCK test is ran before it and so we are not getting to the point where it is executed during our CI run? As such, I have just committed https://github.com/jbosstm/narayana/commit/858ac7d463b18f391712acbf4e0f67... on the LRA branch and am re-running your PR. > 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, 4 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: --------------------------------------- [~tomjenkinson] Sorry, I am not sure what you mean. Please do not associate this issue with my open PRs. This is really a different use-case targeting recovery with failing AfterLRA calls. Let's rather forget about Forget for now :). The issue is that this added test FailingParticipantCallsIT (which is only AfterLRA) is a valid scenario and it should be passing. Just to put in order. The TCK test you have in mind is testing forget without recovery. This issue will manifest also in the PR if recovery is needed because the non-empty arraylist in the Transaction object (afterLRAListeners/endLRAListeners) doesn't mandate itself that the LRA is still recovering and that is why I propose to move both calls to the LRARecord (H_H). > 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, 4 months

1
0
0 / 0

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

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3240?page=com.atlassian.jira.plugin... ] Thomas Jenkinson updated JBTM-3240: ----------------------------------- Fix Version/s: 5.next > 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 > Fix For: 5.next > > > 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, 4 months

1
0
0 / 0

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

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3239: ---------------------------------------- [~mstefank] please can you add more detail to the description regarding the circumstances when they are not? Also, I am not really sure how to interpret the steps to reproduce - is FailingParticipantCallsIT ran after the TCK one that is currently failing on the PR itself? Thanks > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3241) Create a test to validate that the LRA coordinator getStatus query returns a state that matches the state model

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3241: -------------------------------------- Summary: Create a test to validate that the LRA coordinator getStatus query returns a state that matches the state model Key: JBTM-3241 URL: https://issues.redhat.com/browse/JBTM-3241 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Affects Versions: 5.10.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The LRA coordinator acts as a participant when LRA's are nested. We need a test that validates that the correct participant states are reported in accordance with Figure 3. Participant State Model of the [LRA participant state model|https://github.com/eclipse/microprofile-lra/blob/master/spec/src/ma...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3240?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3240: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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, 4 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: ---------------------------------------- [~mstefank] ok, I see, I think I understand your point now. >From my perspective I would say that successful calls of {{Complete}} to all participants and the failure of the {{AfterLRA}} should be two different states. The LRA is finished when all participants finish successfully. And should be advertised that way at that time to "the external viewer". From this I think it would be good to have a special "state" for the unfiished {{AfterLRA}} calls. My two cents. > 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, 4 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: --------------------------------------- [~ochaloup] to answer your question please check https://issues.redhat.com/browse/JBTM-3228. There is a pseudo new use case for Forget calls. But in general, your perspective is right. > 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. This is precisely the reason why I am asking. The participant (let's stick with afterLRA only) will be already Completed/Compensated but if subsequent fterLRA call fails it will appear in the recovery call as not yet completed (because it will return H_H). So we internally know it is already completed/compensated but for the external viewer, this information is not available -- there is no difference between failing Complete/Compensate call and failing AfterLRA call from the external perspective. I am not sure if this is a problem because LRA will truly be finished (removed from ObjectStore) only when even all AfterLRA calls are delivered. > 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, 4 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 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" in your question? It could be I missed something. To summarize my perspective - 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 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. > 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, 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 January 2020