January 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3062) Include a test for LRA context propagation across a "non-LRA aware" service

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3062?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3062: ---------------------------------------- [~mmusgrov] I think the fix version should be removed > Include a test for LRA context propagation across a "non-LRA aware" service > --------------------------------------------------------------------------- > > Key: JBTM-3062 > URL: https://issues.redhat.com/browse/JBTM-3062 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.7.Final > > > If a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and service A in turn calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. A test is needed for this behaviour. > This issue relates to https://github.com/eclipse/microprofile-lra/issues/7 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3072) Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3072?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3072: ---------------------------------------- [~mmusgrov] Perhaps the fix version should be empty and the resolution be changed to "Migrated to another ITS"? > Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose > ---------------------------------------------------------------------------------------- > > Key: JBTM-3072 > URL: https://issues.redhat.com/browse/JBTM-3072 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.7.Final > > > Add a test that verifies the correct behaviour when a method is annotated with both REQUIRES_NEW and delayClose, ie something like: > {code} > @PUT > @Path(ActivityController.ACCEPT_WORK) > @LRA(value = LRA.Type.REQUIRES_NEW, delayClose = true) > public Response doInNewLRA( ....) {...} > {code} > The expected behaviour is: > {code} > /** > * If called outside a LRA context a new LRA will be created for the > * the duration of the method call and when the call completes it will > * be closed (this behaviour can be overridden using the > * {@link LRA#delayClose} attribute). > * > * If called inside a LRA context it will be suspended and a new LRA > * context will be created for the duration of the call. When the method > * finishes this new LRA will be closed and the original context will be > * resumed. This behaviour can be overridden using the > * {@link LRA#delayClose} attribute) in which case the original LRA > * remains suspended and the new LRA becomes the active one and only > * when that one is terminated will the original context be resumed. > */ > REQUIRES_NEW, > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2953) Support asynchronous LRA participants

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-2953?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-2953: ---------------------------------------- [~mmusgrov] I don't think this looks to have been part of https://github.com/jbosstm/narayana/compare/5.9.6.Final...5.9.8.Final so I wonder about the fix version? > Support asynchronous LRA participants > ------------------------------------- > > Key: JBTM-2953 > URL: https://issues.redhat.com/browse/JBTM-2953 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.7.Final > > > When an asynchronous jax-rs method is annotated as an LRA (ie has the @LRA annotation), for example: > {code} > @GET > @LRA > public void someAction(@Suspended AsyncResponse ar) throws InterruptedException { > ... > } > {code} > the LRA filter does not respect the asynchronous nature of the call. > What needs to happen is for LRA jax-rs filter (ServerLRAFilter.java) to issue an asynchronous join request to the coordinator and to link that future to the jax-rs resource AsyncResponse callback. > And since the ServerLRAFilter cannot immediately supply the LRAId to the resource method we also need a method on LRAClient analogous to getCurrent but which returns a Future for the lra id. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3173) Check that the LRA quickstarts work with the latest MP-LRA snapshot

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3173?page=com.atlassian.jira.plugin... ] Thomas Jenkinson updated JBTM-3173: ----------------------------------- Component/s: Quickstarts (was: Demonstrator) > Check that the LRA quickstarts work with the latest MP-LRA snapshot > ------------------------------------------------------------------- > > Key: JBTM-3173 > URL: https://issues.redhat.com/browse/JBTM-3173 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA, Quickstarts > Affects Versions: 5.9.6.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.7.Final > > > The LRA quickstarts in the rts/lra-examples need updating to work on the latest MP-LRA snapshot release -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3170) BasicXARecovery class calculates the name of the XA recovery properties file incorrectly if a number of connections is included

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3170?page=com.atlassian.jira.plugin... ] Thomas Jenkinson updated JBTM-3170: ----------------------------------- Component/s: Transactional Driver > BasicXARecovery class calculates the name of the XA recovery properties file incorrectly if a number of connections is included > ------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3170 > URL: https://issues.redhat.com/browse/JBTM-3170 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Affects Versions: 5.9.6.Final > Reporter: Simon Dallaway > Assignee: Ondrej Chaloupka > Priority: Trivial > Fix For: 5.9.7.Final > > > The procedure initialise of BasicXARecovery incorrectly calculates the name of the XA recovery properties file if a number of connections is included > The current code is > fileName = parameter.substring(0, breakPosition - 1); > The correct code should be > fileName = parameter.substring(0, breakPosition); -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3116) Temporarily disable LRA quickstarts until the MP LRA spec is more stable

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3116?page=com.atlassian.jira.plugin... ] Thomas Jenkinson updated JBTM-3116: ----------------------------------- Component/s: Quickstarts (was: Demonstrator) > Temporarily disable LRA quickstarts until the MP LRA spec is more stable > ------------------------------------------------------------------------ > > Key: JBTM-3116 > URL: https://issues.redhat.com/browse/JBTM-3116 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA, Quickstarts > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.7.Final > > > The MP LRA draft spec has recently undergone a lot of churn and we need to bring both the narayana implementation and the quickstarts into line with those changes. While that work is being undertaken the quickstarts should be disabled so that users and CI do not use non-working examples. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3182) Fix basic LRA tests

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3182?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3182: ---------------------------------------- There seems to be a commit https://github.com/jbosstm/narayana/commit/256a86fd3cfaaeb687685734c06717... - was it enough? > Fix basic LRA tests > ------------------- > > Key: JBTM-3182 > URL: https://issues.redhat.com/browse/JBTM-3182 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.7.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.9.8.Final > > > lra-test/basic is unable to run because of wrong CDI configuration after latest LRA upgrade: > {code:java} > ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002025: Unknown exception while executing GET /root/participant/lra: java.lang.NullPointerException > at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:311) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3182) Fix basic LRA tests

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3182?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3182: ---------------------------------------- [~mmusgrov] this has a fixversion but is reopened? > Fix basic LRA tests > ------------------- > > Key: JBTM-3182 > URL: https://issues.redhat.com/browse/JBTM-3182 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.7.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.9.8.Final > > > lra-test/basic is unable to run because of wrong CDI configuration after latest LRA upgrade: > {code:java} > ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002025: Unknown exception while executing GET /root/participant/lra: java.lang.NullPointerException > at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:311) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3208) Include an LRA quickstart that includes an embedded coordinator

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3208?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3208: ---------------------------------------- [~mmusgrov] this has a fixversion but is open? > Include an LRA quickstart that includes an embedded coordinator > --------------------------------------------------------------- > > Key: JBTM-3208 > URL: https://issues.redhat.com/browse/JBTM-3208 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.8.Final > > > The LRA quickstarts all use an external coordinator for managing the lifecycle of an LRA. We should include a quickstart the demonstrates how to embed the coordinator with the service. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3226) Byteman rule check failure with version 4.0.9

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3226?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3226: ----------------------------------- Fix Version/s: 5.10.2.Final (was: 5.10.1.Final) > Byteman rule check failure with version 4.0.9 > --------------------------------------------- > > Key: JBTM-3226 > URL: https://issues.redhat.com/browse/JBTM-3226 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.10.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.10.2.Final > > > Our byteman scripts fail rule checking when using byteman version 4.0.9: > {quote} > [ERROR] Failed to execute goal org.jboss.byteman:byteman-rulecheck-maven-plugin:4.0.9:rulecheck (rulecheck) on project arjuna: Execution rulecheck of goal org.jboss.byteman:byteman-rulecheck-maven-plugin:4.0.9:r > ulecheck failed.: NullPointerException -> [Help 1] > [ERROR] > {quote} > The byteman bug report is issue https://issues.jboss.org/browse/BYTEMAN-392 > The byteman upgrade was introduced by pull request 1530 (https://github.com/jbosstm/narayana/pull/1530) > The issue occurs whenever a byteman script contains more that one rule (so the workaround is to only have single rule scripts). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 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