January 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3243) Observer method for ApplicationScoped bean destruction creates a new bean

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Michael Musgrove created pull request #1547 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Observer method for ApplicationScoped bean destruction creates a new bean > ------------------------------------------------------------------------- > > Key: JBTM-3243 > URL: https://issues.redhat.com/browse/JBTM-3243 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@ActivateRequestContext` will ensure the correct application scoped bean used. So instead of > {code} > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) > {code} > use > {code} > @ActivateRequestContext > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) { > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3243) Observer method for ApplicationScoped bean destruction creates a new bean

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3243: -------------------------------------- Summary: Observer method for ApplicationScoped bean destruction creates a new bean Key: JBTM-3243 URL: https://issues.redhat.com/browse/JBTM-3243 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@ActivateRequestContext` will ensure the correct application scoped bean used. So instead of {code} void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) {code} use {code} @ActivateRequestContext void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) { {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3242) Starting an LRA using a POST request does not set the HTTP Location header

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3242: -------------------------------------- Summary: Starting an LRA using a POST request does not set the HTTP Location header Key: JBTM-3242 URL: https://issues.redhat.com/browse/JBTM-3242 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next LRA's are created by sending an HTTP POST request to the coordinator. POST requests that create new resources normally return the newly created resource in the Location header [1] or based on the "effective request URI" [2]. The coordinator implementation does not set the Location header. [1] https://tools.ietf.org/html/rfc7231#section-6.3.2 [2] https://tools.ietf.org/html/rfc7230#section-5.5 -- 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 Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3239: ---------------------------------------- By the way, I am not really clear on the proposal to address the issue. Does it include this different state for unfinished AfterLRA calls? The state would currently be one from https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes... would it not? Where would you propose to add the new boolean? > 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-3239) Failing AfterLRA participant calls are not repeated with recovery module

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3239: ---------------------------------------- [~mstefank] I think we should discuss the proposed solution on the developer space: https://developer.jboss.org/en/jbosstm/dev/content?filterID=contentstatus... > 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-3239) Failing AfterLRA participant calls are not repeated with recovery module

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3239: ---------------------------------------- Thanks! > 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-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 commented on JBTM-3239: --------------------------------------- [~tomjenkinson] I updated the title and description. And for the FailingParticipantCallsIT#testFailingAfterLRA you are right. It is not running because it's after TCK. Thanks for the fix. If there are no objections (even if I would like to wait for [~mmusgrov] opinion which was similar to my proposition) I would start implementing this so we can get TCK and test suite passing as soon as possible. > 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-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: ---------------------------------- Description: 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. was:The afterLRA calls are currently delivered only twice when the LRA is finished (twice because of > 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-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: ---------------------------------- Description: The afterLRA calls are currently delivered only twice when the LRA is finished (twice because of > 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 -- 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 edited comment on JBTM-3239 at 1/8/20 5:04 AM: --------------------------------------------------------------- I would propose to move the afterLRA recovery module handling (meaning the repetition of a failed AfterLRA invocation in the previous run of the recovery module) 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] was (Author: mstefank): 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 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, 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