March 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3271) javadoc error when building with JDK11

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3271: -------------------------------------- Summary: javadoc error when building with JDK11 Key: JBTM-3271 URL: https://issues.redhat.com/browse/JBTM-3271 Project: JBoss Transaction Manager Issue Type: Bug Components: Build System Affects Versions: 5.10.3.Final Reporter: Michael Musgrove Fix For: 5.next When we build ArjunaCore/arjunacore using JDK11 we get the following error: bq. javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/8/docs/api/ are in the unnamed module. A fix is to configure the javadoc plugin (org.apache.maven.plugins:maven-javadoc-plugin) to use <source>8</source> in the plugin configuration section. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2419) Reduce the number of performance regression tests that run against a PR

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-2419?page=com.atlassian.jira.plugin... ] Mayank Kunwar reassigned JBTM-2419: ----------------------------------- Assignee: Mayank Kunwar > Reduce the number of performance regression tests that run against a PR > ----------------------------------------------------------------------- > > Key: JBTM-2419 > URL: https://issues.redhat.com/browse/JBTM-2419 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Minor > Fix For: 5.next > > > We run our JMH tests multiple times in order to estimate run-to-run variance. The [JMH docs|http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/m...] state: > bq. JVMs are complex systems, and the non-determinism is inherent for them. This requires us to always account the run-to-run variance as the one of the effects in our experiments. Forking aggregates the results across several JVM launches. > Currently we set the number of forks to 10. We run each test 6 times with each run lasting 1 min. Since we have 10 tests this means it takes 10 * 10 * 6 minutes for the benchmarks to complete. In the future we want to keep adding new performance tests and the time taken to run a PR will become prohibitive. I would like to propose one of the following solutions: > - reduce the number of forks; > - run a subset of performance tests on each PR and then run them all once a week or so on the main build > My preference is to reduce the number of forks to 3. Note that the PR requester has the option to disable performance tests for his PR (by including !PERF in the comment section). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2419) Reduce the number of performance regression tests that run against a PR

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-2419?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-2419: ----------------------------------- Summary: Reduce the number of performance regression tests that run against a PR (was: Consider reducing the number of performance regression tests ran against a PR) > Reduce the number of performance regression tests that run against a PR > ----------------------------------------------------------------------- > > Key: JBTM-2419 > URL: https://issues.redhat.com/browse/JBTM-2419 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > We run our JMH tests multiple times in order to estimate run-to-run variance. The [JMH docs|http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/m...] state: > bq. JVMs are complex systems, and the non-determinism is inherent for them. This requires us to always account the run-to-run variance as the one of the effects in our experiments. Forking aggregates the results across several JVM launches. > Currently we set the number of forks to 10. We run each test 6 times with each run lasting 1 min. Since we have 10 tests this means it takes 10 * 10 * 6 minutes for the benchmarks to complete. In the future we want to keep adding new performance tests and the time taken to run a PR will become prohibitive. I would like to propose one of the following solutions: > - reduce the number of forks; > - run a subset of performance tests on each PR and then run them all once a week or so on the main build > My preference is to reduce the number of forks to 3. Note that the PR requester has the option to disable performance tests for his PR (by including !PERF in the comment section). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2419) Consider reducing the number of performance regression tests ran against a PR

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-2419?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-2419: ----------------------------------- Summary: Consider reducing the number of performance regression tests ran against a PR (was: Consider reducing the number of JMH perf test forks on PRs) > Consider reducing the number of performance regression tests ran against a PR > ----------------------------------------------------------------------------- > > Key: JBTM-2419 > URL: https://issues.redhat.com/browse/JBTM-2419 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > We run our JMH tests multiple times in order to estimate run-to-run variance. The [JMH docs|http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/m...] state: > bq. JVMs are complex systems, and the non-determinism is inherent for them. This requires us to always account the run-to-run variance as the one of the effects in our experiments. Forking aggregates the results across several JVM launches. > Currently we set the number of forks to 10. We run each test 6 times with each run lasting 1 min. Since we have 10 tests this means it takes 10 * 10 * 6 minutes for the benchmarks to complete. In the future we want to keep adding new performance tests and the time taken to run a PR will become prohibitive. I would like to propose one of the following solutions: > - reduce the number of forks; > - run a subset of performance tests on each PR and then run them all once a week or so on the main build > My preference is to reduce the number of forks to 3. Note that the PR requester has the option to disable performance tests for his PR (by including !PERF in the comment section). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3270) Rollback of inbound REST-AT transaction causes warning message being printed under server.log

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3270?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3270: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1574 > Rollback of inbound REST-AT transaction causes warning message being printed under server.log > --------------------------------------------------------------------------------------------- > > Key: JBTM-3270 > URL: https://issues.redhat.com/browse/JBTM-3270 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > When a inbound REST-AT Transaction is rolled-back while it was not yet persisted into object store then a warning message is shown in the log > {quote} > [com.arjuna.ats.arjuna] (default task-2) ARJUNA012269: UNKNOWN state for object with uid 0:ffff0a00000a:1f1301f3:5e7de5f0:37 , type /REST-AT/Integration/ParticipantInformationRecoveryRecord > {quote} > The reason for this is that REST-AT {{RecoveryManager}} instance does not track which participants were really persisted ({{ObjectStore.write_committed}}). Regardless of this fact the removal is attempted and the underlaying removal found it knows nothing about such state > https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaCore/arjuna/c... > This should be probably handled similarly to the XTS bridge > https://github.com/jbosstm/narayana/blob/5.10.4.Final/XTS/recovery/src/or... > where {{uidMap}} is used to not issue removal of non-persisted items. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3270) Rollback of inbound REST-AT transaction causes warning message being printed under server.log

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3270: -------------------------------------- Summary: Rollback of inbound REST-AT transaction causes warning message being printed under server.log Key: JBTM-3270 URL: https://issues.redhat.com/browse/JBTM-3270 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.10.3.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka When a inbound REST-AT Transaction is rolled-back while it was not yet persisted into object store then a warning message is shown in the log {quote} [com.arjuna.ats.arjuna] (default task-2) ARJUNA012269: UNKNOWN state for object with uid 0:ffff0a00000a:1f1301f3:5e7de5f0:37 , type /REST-AT/Integration/ParticipantInformationRecoveryRecord {quote} The reason for this is that REST-AT {{RecoveryManager}} instance does not track which participants were really persisted ({{ObjectStore.write_committed}}). Regardless of this fact the removal is attempted and the underlaying removal found it knows nothing about such state https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaCore/arjuna/c... This should be probably handled similarly to the XTS bridge https://github.com/jbosstm/narayana/blob/5.10.4.Final/XTS/recovery/src/or... where {{uidMap}} is used to not issue removal of non-persisted items. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3155) Remove implementation of LRAManagement

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3155?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3155: ----------------------------------- Fix Version/s: 5.next > Remove implementation of LRAManagement > -------------------------------------- > > Key: JBTM-3155 > URL: https://issues.redhat.com/browse/JBTM-3155 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > The specification removed LRAManagement and associated classes in [this commit|https://github.com/eclipse/microprofile-lra/commit/93e76930b3e5dbc...]. As we will have a record of this implementation in GitHub history we can remove this implementation for now. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3163?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3163: ----------------------------------- Fix Version/s: 5.next > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.redhat.com/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java.... This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450]) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

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

1
0
0 / 0

[JBoss JIRA] (JBTM-3260) On publishing a new Narayana release there should be created Quarkus PR to update Narayana version

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3260?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3260: ----------------------------------- Fix Version/s: 5.next > On publishing a new Narayana release there should be created Quarkus PR to update Narayana version > -------------------------------------------------------------------------------------------------- > > Key: JBTM-3260 > URL: https://issues.redhat.com/browse/JBTM-3260 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.next > > > As currently when a Narayana minor release is published it's usual to create a WildFly pull request which updates the Narayana version to the most up-to-date. > This functionality is automatized in the release script: > https://github.com/jbosstm/narayana/blob/5.10.4.Final/narayana-release-pr... > It would be good to have a similar functionality for the Quarkus. Narayana is the component managing JTA trasaction there and it would be good to pass there the newest version as well. > Narayana version could be updated at: > https://github.com/quarkusio/quarkus/blob/1.2.1.Final/bom/runtime/pom.xml... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 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 March 2020