February 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3217) Take Compensate and Complete timeout information from the LRA annotation in the same class

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3217?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3217: ----------------------------------- Priority: Blocker (was: Major) > Take Compensate and Complete timeout information from the LRA annotation in the same class > ------------------------------------------------------------------------------------------ > > Key: JBTM-3217 > URL: https://issues.redhat.com/browse/JBTM-3217 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Blocker > Fix For: 5.next > > > Update the handling of timeout information for Compensate and Complete according to the specification. Now it's defined in the LRA annotation similarly as for the new LRA. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3204) Upgrade LRA TCK recovery handling to accommodate specification changes

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3204?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3204: ----------------------------------- Priority: Blocker (was: Major) > Upgrade LRA TCK recovery handling to accommodate specification changes > ----------------------------------------------------------------------- > > Key: JBTM-3204 > URL: https://issues.redhat.com/browse/JBTM-3204 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Blocker > Fix For: 5.next > > > LRA TCK added a new way of handling LRA recovery in https://github.com/eclipse/microprofile-lra/commit/52b799768b3d0fa1746f2b.... Update the implementation to accommodate these changes. > Also update the LRA versions to the latest snapshots: > <version.microprofile.lra.api>1.0-20190927.061209-550</version.microprofile.lra.api> > <version.microprofile.lra.tck>1.0-20190927.061211-550</version.microprofile.lra.tck> > diff: [https://github.com/eclipse/microprofile-lra/compare/1.0-RC1...fab960eede3...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3245) Check the behaviour when LRA enlistment fails due to coordinator unavailability

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3245?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3245: ----------------------------------- Priority: Blocker (was: Major) > Check the behaviour when LRA enlistment fails due to coordinator unavailability > ------------------------------------------------------------------------------- > > Key: JBTM-3245 > URL: https://issues.redhat.com/browse/JBTM-3245 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > There is no test that verifies an LRA is cancelled if a participant tries to join with an LRA and fails because an external coordinator is unavailable. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3239: ----------------------------------- Priority: Blocker (was: Major) > 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: Michael Musgrove > Priority: Blocker > > 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, 10 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: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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 > 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, 10 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: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1559 (was: https://github.com/jbosstm/narayana/pull/1468) > 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 > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3200) crashrecovery12 CrashRecovery12_Test06 failed

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3200?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3200: ---------------------------------------- is it possible that a connection was made to another container on 172.17.0.13 due to docker? > crashrecovery12 CrashRecovery12_Test06 failed > --------------------------------------------- > > Key: JBTM-3200 > URL: https://issues.redhat.com/browse/JBTM-3200 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Thomas Jenkinson > Priority: Major > Attachments: CrashRecovery12_Test06-fail.zip, CrashRecovery12_Test06-pass.zip > > > One of the crash recovery tests failed. > I will attach logs from a failed run and a passed one. Of interest in the pass case you can see the recovery is _not_ able to connect to the previous socket 33690 but in the fail case it is somehow as if the System.exit did not cause the JVM to immediately terminate. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3200) crashrecovery12 CrashRecovery12_Test06 failed

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3200?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3200: ---------------------------------------- Perhaps it did terminate and it looks maybe whatever the recovery manager connected to on 38110 was not what it expected? > crashrecovery12 CrashRecovery12_Test06 failed > --------------------------------------------- > > Key: JBTM-3200 > URL: https://issues.redhat.com/browse/JBTM-3200 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Thomas Jenkinson > Priority: Major > Attachments: CrashRecovery12_Test06-fail.zip, CrashRecovery12_Test06-pass.zip > > > One of the crash recovery tests failed. > I will attach logs from a failed run and a passed one. Of interest in the pass case you can see the recovery is _not_ able to connect to the previous socket 33690 but in the fail case it is somehow as if the System.exit did not cause the JVM to immediately terminate. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3137) Too much variance in the performance PR checker

by Anonymous (Jira)

[ https://issues.redhat.com/browse/JBTM-3137?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when mayankkunwar created pull request #64 in GitHub ----------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Too much variance in the performance PR checker > ----------------------------------------------- > > Key: JBTM-3137 > URL: https://issues.redhat.com/browse/JBTM-3137 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.next > > > The PERF axis of the PR checker job runs some tests to validate that the PR does not introduce any regressions but the axis is not useful since there is too much variance in the runs. For example PR https://github.com/jbosstm/narayana/pull/1437 ran 3 times each producing wildly different results. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3137) Too much variance in the performance PR checker

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3137?page=com.atlassian.jira.plugin... ] Mayank Kunwar reassigned JBTM-3137: ----------------------------------- Assignee: Mayank Kunwar (was: Michael Musgrove) > Too much variance in the performance PR checker > ----------------------------------------------- > > Key: JBTM-3137 > URL: https://issues.redhat.com/browse/JBTM-3137 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.next > > > The PERF axis of the PR checker job runs some tests to validate that the PR does not introduce any regressions but the axis is not useful since there is too much variance in the runs. For example PR https://github.com/jbosstm/narayana/pull/1437 ran 3 times each producing wildly different results. -- 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 February 2020