December 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3238) Coordinator#completeNestedLRA and Coordinator#compensateNestedLRA should return ParticipantStatus

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3238?page=com.atlassian.jira.plugin... ] Martin Stefanko updated JBTM-3238: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1540 > Coordinator#completeNestedLRA and Coordinator#compensateNestedLRA should return ParticipantStatus > ------------------------------------------------------------------------------------------------- > > Key: JBTM-3238 > URL: https://issues.redhat.com/browse/JBTM-3238 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > This is a follow up on https://issues.redhat.com/browse/JBTM-3234 where I missed two other methods that represent complete and compensate which should also return ParticipantStatus. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3238) Coordinator#completeNestedLRA and Coordinator#compensateNestedLRA should return ParticipantStatus

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3238: ------------------------------------- Summary: Coordinator#completeNestedLRA and Coordinator#compensateNestedLRA should return ParticipantStatus Key: JBTM-3238 URL: https://issues.redhat.com/browse/JBTM-3238 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.1.Final Reporter: Martin Stefanko Assignee: Martin Stefanko This is a follow up on https://issues.redhat.com/browse/JBTM-3234 where I missed two other methods that represent complete and compensate which should also return ParticipantStatus. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3237) LRA service singleton invoked twice singletons are created twice when the CDI observers subsystem is used

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3237: -------------------------------------- Summary: LRA service singleton invoked twice singletons are created twice when the CDI observers subsystem is used Key: JBTM-3237 URL: https://issues.redhat.com/browse/JBTM-3237 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Reporter: Michael Musgrove Assignee: Michael Musgrove When the LRA coordinator is ran with Quarkus the LRAService ApplicationScoped bean initialise event is triggered twice. I noticed this problem when running with Quarkus (https://github.com/quarkusio/quarkus/issues/2673) but the resolution of that issue was that CDI is under-specified in this area. The fix for our needs is to observe the bean being destructed using the [Quarkus ShutdownEvent|https://quarkus.io/guides/lifecycle]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3236) Upgrade to latest byteman release

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3236: -------------------------------------- Summary: Upgrade to latest byteman release Key: JBTM-3236 URL: https://issues.redhat.com/browse/JBTM-3236 Project: JBoss Transaction Manager Issue Type: Quality Risk Components: Testing Affects Versions: 5.10.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next JBTM-3226 (Byteman rule check failure with version 4.0.9) introduced a byteman version change but the new version contained a bug which has now been fixed in 4.0.10 (see BYTEMAN-391) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 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: ----------------------------------- Status: Resolved (was: Pull Request Sent) 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 > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3234) Coordinator#getNestedLRAStatus should return ParticipantStatus

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3234?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3234: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Coordinator#getNestedLRAStatus should return ParticipantStatus > -------------------------------------------------------------- > > Key: JBTM-3234 > URL: https://issues.redhat.com/browse/JBTM-3234 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > the method Coordinator#getNestedLRAStatus is used in LRA processing as normal `@Status` callback however currently it returns the status of the nested LRA which is of type LRAStatus and not ParticipantStatus which is the correct return type of `@Status` methods according to the specification. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

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

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3232?page=com.atlassian.jira.plugin... ] Martin Stefanko updated JBTM-3232: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1539 > 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 > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3234) Coordinator#getNestedLRAStatus should return ParticipantStatus

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3234?page=com.atlassian.jira.plugin... ] Martin Stefanko updated JBTM-3234: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1538 > Coordinator#getNestedLRAStatus should return ParticipantStatus > -------------------------------------------------------------- > > Key: JBTM-3234 > URL: https://issues.redhat.com/browse/JBTM-3234 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > the method Coordinator#getNestedLRAStatus is used in LRA processing as normal `@Status` callback however currently it returns the status of the nested LRA which is of type LRAStatus and not ParticipantStatus which is the correct return type of `@Status` methods according to the specification. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 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 commented on JBTM-3232: ---------------------------------------- So we just need to return a participant status (ie fix JBTM-3234) and give the status endpoint a different path. Don't change any of the other paths. > 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 > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3235) Performance regression tests should consult the "Score Error" before reporting regressions

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3235?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3235: ----------------------------------- Description: We perform [microbenchmark performance testing of JTA|https://github.com/jbosstm/performance/tree/master/narayana/ArjunaJTA...] and we have Jenkins CI jobs (btny-pulls-performance and narayana-performance-version-comparison) that do regression testing against different versions of the product. These tests use [JMH|https://openjdk.java.net/projects/code-tools/jmh/] to perform the test runs. The results of each run are reported as a CSV file in the following example format: {code} "Version","Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" 5.5.32.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,217253.976024,8720.877211,"ops/s" 5.9.0.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,216552.983213,6586.482104,"ops/s" {code} This example shows a comparison between versions 5.5.32.Final and 5.9.0.Final. The data shows that we measured using a mode called "thrpt" (ie transactions per second or TPS) and the Score shows the TPS was 217253 vers us 216552. There is also a Score Error which I understand indicates the upper and lower error bars for the measurement. None of our jobs take account of the error bars when reporting regressions. What we need to do is look at the Score Error to see if the runs are within tolerance before reporting a regression. An example of how to manually run a regression test is as follows: {code} git clone https://github.com/jbosstm/performance # clone the performance git repo cd performance export JMHARGS="-t 240 -r 30 -f 3 -wi 5 -i 5" # tune the test using JMH config params # and then do a performance run: export version=5.5.32.Final # set the target narayana version ./build.sh -f narayana/ArjunaJTA/jta/pom.xml clean install -DskipTests -Dnarayana.version=$version java -classpath narayana/ArjunaJTA/jta/target/classes/ -Dcom.arjuna.ats.arjuna.common.propertiesFile=jbossts-properties.xml -jar narayana/ArjunaJTA/jta/target/benchmarks.jar io.narayana.perf.product.NarayanaComparison.* $JMHARGS -rf csv -rff io.narayana.perf.product.NarayanaComparison-$version.csv {code} The results are in the named csv file. Then do the same for the second version was: We perform [microbenchmark performance testing of JTA|https://github.com/jbosstm/performance/tree/master/narayana/ArjunaJTA...] and we have Jenkins CI jobs (btny-pulls-performance and narayana-performance-version-comparison) that do regression testing against different versions of the product. These tests use [JMH|https://openjdk.java.net/projects/code-tools/jmh/] to perform the test runs. The results of each run are reported as a CSV file in the following example format: "Version","Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" 5.5.32.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,217253.976024,8720.877211,"ops/s" 5.9.0.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,216552.983213,6586.482104,"ops/s" This example shows a comparison between versions 5.5.32.Final and 5.9.0.Final. The data shows that we measured using a mode called "thrpt" (ie transactions per second or TPS) and the Score shows the TPS was 217253 vers us 216552. There is also a Score Error which I understand indicates the upper and lower error bars for the measurement. None of our jobs take account of the error bars when reporting regressions. What we need to do is look at the Score Error to see if the runs are within tolerance before reporting a regression. An example of how to manually run a regression test is as follows: {code} git clone https://github.com/jbosstm/performance # clone the performance git repo cd performance export JMHARGS="-t 240 -r 30 -f 3 -wi 5 -i 5" # tune the test using JMH config params # and then do a performance run: export version=5.5.32.Final # set the target narayana version ./build.sh -f narayana/ArjunaJTA/jta/pom.xml clean install -DskipTests -Dnarayana.version=$version java -classpath narayana/ArjunaJTA/jta/target/classes/ -Dcom.arjuna.ats.arjuna.common.propertiesFile=jbossts-properties.xml -jar narayana/ArjunaJTA/jta/target/benchmarks.jar io.narayana.perf.product.NarayanaComparison.* $JMHARGS -rf csv -rff io.narayana.perf.product.NarayanaComparison-$version.csv {code} The results are in the named csv file. Then do the same for the second version > Performance regression tests should consult the "Score Error" before reporting regressions > ------------------------------------------------------------------------------------------ > > Key: JBTM-3235 > URL: https://issues.redhat.com/browse/JBTM-3235 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > We perform [microbenchmark performance testing of JTA|https://github.com/jbosstm/performance/tree/master/narayana/ArjunaJTA...] and we have Jenkins CI jobs (btny-pulls-performance and narayana-performance-version-comparison) that do regression testing against different versions of the product. > These tests use [JMH|https://openjdk.java.net/projects/code-tools/jmh/] to perform the test runs. The results of each run are reported as a CSV file in the following example format: > {code} > "Version","Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" > 5.5.32.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,217253.976024,8720.877211,"ops/s" > 5.9.0.Final,"io.narayana.perf.product.NarayanaComparison.test","thrpt",240,15,216552.983213,6586.482104,"ops/s" > {code} > This example shows a comparison between versions 5.5.32.Final and 5.9.0.Final. The data shows that > we measured using a mode called "thrpt" (ie transactions per second or TPS) and the Score shows the TPS was 217253 vers > us 216552. There is also a Score Error which I understand indicates the upper and lower error bars for the measurement. > None of our jobs take account of the error bars when reporting regressions. What we need to do is look at the Score Error to see if the runs are within tolerance before reporting a regression. > An example of how to manually run a regression test is as follows: > {code} > git clone https://github.com/jbosstm/performance # clone the performance git repo > cd performance > export JMHARGS="-t 240 -r 30 -f 3 -wi 5 -i 5" # tune the test using JMH config params > # and then do a performance run: > export version=5.5.32.Final # set the target narayana version > ./build.sh -f narayana/ArjunaJTA/jta/pom.xml clean install -DskipTests -Dnarayana.version=$version > java -classpath narayana/ArjunaJTA/jta/target/classes/ -Dcom.arjuna.ats.arjuna.common.propertiesFile=jbossts-properties.xml -jar narayana/ArjunaJTA/jta/target/benchmarks.jar io.narayana.perf.product.NarayanaComparison.* $JMHARGS -rf csv -rff io.narayana.perf.product.NarayanaComparison-$version.csv > {code} > The results are in the named csv file. > Then do the same for the second version -- 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 December 2019