June 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3321) The REST-AT inbound bridge provider wrongly uses the customer priority

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3321?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3321: ----------------------------------- Fix Version/s: 5.next > The REST-AT inbound bridge provider wrongly uses the customer priority > ---------------------------------------------------------------------- > > Key: JBTM-3321 > URL: https://issues.redhat.com/browse/JBTM-3321 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > The current REST-AT inbound bridge wrongly uses the user {{@Priority}} value (https://docs.oracle.com/javaee/7/api/javax/ws/rs/Priorities.html#USER). > The transactional interceptor should not be called at the same time as the user interceptors and it has to go before them. > This is a not expected ordering and it may cause issues when a user adds his own provider. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3304) Performance comparison with Atomikos may loop forever

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3304?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3304: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Performance comparison with Atomikos may loop forever > ----------------------------------------------------- > > Key: JBTM-3304 > URL: https://issues.redhat.com/browse/JBTM-3304 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > Fix For: 5.next > > > We have occasionally (though not common) seen our performance comparison (with other open source TMs) job loop forever when Atomikos fails to enlist a resource (for example job http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-performance/4/). > The correct behaviour should be to catch the error and abort the JMH run for that particular comparison. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3304) Performance comparison with Atomikos may loop forever

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3304?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3304: ----------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/jbosstm/performance/pull/71, https://github.com/jbosstm/performance/pull/72, https://github.com/jbosstm/performance/pull/76 > Performance comparison with Atomikos may loop forever > ----------------------------------------------------- > > Key: JBTM-3304 > URL: https://issues.redhat.com/browse/JBTM-3304 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Major > > We have occasionally (though not common) seen our performance comparison (with other open source TMs) job loop forever when Atomikos fails to enlist a resource (for example job http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-performance/4/). > The correct behaviour should be to catch the error and abort the JMH run for that particular comparison. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3318) TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3318?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3318: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jbosstm/narayana/pull/1625, https://github.com/jbosstm/narayana/pull/1637 (was: https://github.com/jbosstm/narayana/pull/1625) > TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI > ------------------------------------------------------------------- > > Key: JBTM-3318 > URL: https://issues.redhat.com/browse/JBTM-3318 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: org.eclipse.microprofile.lra.tck.TckRecoveryTests-output.txt > > > The test {{TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} fails on AMS CI. > The CI is a bit slower and it seems the issue consists of timeout handling. > {code} > [INFO] Running org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 57.021 s <<< FAILURE! - in org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] testCancelWhenParticipantIsUnavailable(org.eclipse.microprofile.lra.tck.TckRecoveryTests) Time elapsed: 28.349 s <<< FAILURE! > java.lang.AssertionError: Compensate on restarted service should have been called. Was -1 expected:<200> but was:<500> > at org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable(TckRecoveryTests.java:215) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3318) TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3318?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3318: ---------------------------------------- If your PoC appears to work I think we should merge your solution and see what effect it has on CI. We can always back out the fix if it doesn't work on our CI (which regularly fails on these two tests). > TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI > ------------------------------------------------------------------- > > Key: JBTM-3318 > URL: https://issues.redhat.com/browse/JBTM-3318 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: org.eclipse.microprofile.lra.tck.TckRecoveryTests-output.txt > > > The test {{TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} fails on AMS CI. > The CI is a bit slower and it seems the issue consists of timeout handling. > {code} > [INFO] Running org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 57.021 s <<< FAILURE! - in org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] testCancelWhenParticipantIsUnavailable(org.eclipse.microprofile.lra.tck.TckRecoveryTests) Time elapsed: 28.349 s <<< FAILURE! > java.lang.AssertionError: Compensate on restarted service should have been called. Was -1 expected:<200> but was:<500> > at org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable(TckRecoveryTests.java:215) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3331) LRA end should not return internal server error when precondition fails as it's considered behaviour by spec

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3331?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3331: ----------------------------------- Workaround Description: (was: L) > LRA end should not return internal server error when precondition fails as it's considered behaviour by spec > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3331 > URL: https://issues.redhat.com/browse/JBTM-3331 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > > I've spent some time with https://issues.redhat.com/browse/JBTM-3318 recently and I have a doubt about behaviour of the LRA. The JBTM-3318 consists of race condition on starting/enlisting/timeouting the LRA. > The same issue makes failing the `TckTests#timeLimit` and `TckRecoveryTests#testCancelWhenParticipantIsUnavailable` on our slow AMS CI. > I don't want to talk now about the TCK failure but about the related behaviour of the Narayana implementation. > The LRA participant defines the {{timeLimit}} (https://github.com/eclipse/microprofile-lra/blob/1.0-M1/tck/src/main/java...). > And what happens is that the client (TCK test) calls the LRA method, the JAX-RS filter starts a LRA on coordinator, meanwhile the timeout limit elapses, the JAX-RS filter tries to enlist the LRA participant to started LRA but it fails as the LRA was cancelled because of timeout. > Now. The possible non-deterministic Narayana behaviour is that in case of failure on LRA participant enlistment the client may or may not get internal server error. > It's because the LRA in timeouted state on client is tried to be cancelled (see https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-client/...). > The {{NarayanaLRAClient#endLRA}} tries to cancel the LRA. But as the coordinator timeouted the LRA then now depends if recovery already removed the LRA or not. If the LRA was not removed yet then {{412, PRECONDITION FAILED}} is returned. If the recovery made it then {{404, NOT FOUDN}} is returned. > Now the {{endLRA}} considers the {{404}} as not a failure that is considered as {{500, INTERNAL SERVER ERROR}} while the {{412, PRECONDITION FAILED}} is considered as internal server error. That should not be that way as the LRA spec considers {{412}} as "correct" error (see https://github.com/eclipse/microprofile-lra/blob/1.0-M1/api/src/main/java...). > Such an anticipated return state should not be reported to client as {{500}} - {{internal server error}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3331) LRA end should not return internal server error when precondition fails as it's considered behaviour by spec

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3331: -------------------------------------- Summary: LRA end should not return internal server error when precondition fails as it's considered behaviour by spec Key: JBTM-3331 URL: https://issues.redhat.com/browse/JBTM-3331 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.5.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka I've spent some time with https://issues.redhat.com/browse/JBTM-3318 recently and I have a doubt about behaviour of the LRA. The JBTM-3318 consists of race condition on starting/enlisting/timeouting the LRA. The same issue makes failing the `TckTests#timeLimit` and `TckRecoveryTests#testCancelWhenParticipantIsUnavailable` on our slow AMS CI. I don't want to talk now about the TCK failure but about the related behaviour of the Narayana implementation. The LRA participant defines the {{timeLimit}} (https://github.com/eclipse/microprofile-lra/blob/1.0-M1/tck/src/main/java...). And what happens is that the client (TCK test) calls the LRA method, the JAX-RS filter starts a LRA on coordinator, meanwhile the timeout limit elapses, the JAX-RS filter tries to enlist the LRA participant to started LRA but it fails as the LRA was cancelled because of timeout. Now. The possible non-deterministic Narayana behaviour is that in case of failure on LRA participant enlistment the client may or may not get internal server error. It's because the LRA in timeouted state on client is tried to be cancelled (see https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-client/...). The {{NarayanaLRAClient#endLRA}} tries to cancel the LRA. But as the coordinator timeouted the LRA then now depends if recovery already removed the LRA or not. If the LRA was not removed yet then {{412, PRECONDITION FAILED}} is returned. If the recovery made it then {{404, NOT FOUDN}} is returned. Now the {{endLRA}} considers the {{404}} as not a failure that is considered as {{500, INTERNAL SERVER ERROR}} while the {{412, PRECONDITION FAILED}} is considered as internal server error. That should not be that way as the LRA spec considers {{412}} as "correct" error (see https://github.com/eclipse/microprofile-lra/blob/1.0-M1/api/src/main/java...). Such an anticipated return state should not be reported to client as {{500}} - {{internal server error}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3318) TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3318?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3318: ---------------------------------------- This consists of timing issue where cancelling of the started LRA may come before LRA participant is enlisted. The exactly same trouble comes at issues with {{TckTests#timeLimit}}. I hoped that the fix of working with {{tck time factor}} will help (see https://github.com/eclipse/microprofile-lra/pull/309, https://github.com/jbosstm/narayana/pull/1623) but neither of that helped. The issue is not directly configurable with time factor, unfortunately. What happens on the Narayana AMS CI is that processing of the Quarkus coordinator and Thorntail TCK testsuite is slow. It happens that at time the {{@LRA}} method is invoked the JAX-RS filter starts the LRA, but meanwhile the timeout defined by {{timeLimit}} elapses (https://github.com/eclipse/microprofile-lra/blob/1.0-M1/tck/src/main/java...) and for the next step which is enlisting of the resource the LRA is {{canceled}}. The enlistment fails. Now, the failure is not deterministic as it could be {{412}} ({{precondition failed}}) in case there is still LRA on coordinator or {{404}} ({{gone}}) if the LRA was removed by recovery. In case of {{gone}} there is not thrown the exception in case of {{412}} there is thrown exception to client. What is needed is to find a way to adjust the {{timeLimit}} value based on the value of the tck timeout factor system property {{lra.tck.timeout.factor}}. That's a bit problematic as the annotation value is not adjustable during runtime easily. My PoC works with reflection on the classes: https://github.com/ochaloup/narayana/commit/9f8127a1a4c771f2fae8690a40f0b... > TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI > ------------------------------------------------------------------- > > Key: JBTM-3318 > URL: https://issues.redhat.com/browse/JBTM-3318 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: org.eclipse.microprofile.lra.tck.TckRecoveryTests-output.txt > > > The test {{TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} fails on AMS CI. > The CI is a bit slower and it seems the issue consists of timeout handling. > {code} > [INFO] Running org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 57.021 s <<< FAILURE! - in org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] testCancelWhenParticipantIsUnavailable(org.eclipse.microprofile.lra.tck.TckRecoveryTests) Time elapsed: 28.349 s <<< FAILURE! > java.lang.AssertionError: Compensate on restarted service should have been called. Was -1 expected:<200> but was:<500> > at org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable(TckRecoveryTests.java:215) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3318) TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3318?page=com.atlassian.jira.plugin... ] Work on JBTM-3318 started by Ondrej Chaloupka. ---------------------------------------------- > TckRecoveryTests#testCancelWhenParticipantIsUnavailable fails on CI > ------------------------------------------------------------------- > > Key: JBTM-3318 > URL: https://issues.redhat.com/browse/JBTM-3318 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: org.eclipse.microprofile.lra.tck.TckRecoveryTests-output.txt > > > The test {{TckRecoveryTests#testCancelWhenParticipantIsUnavailable}} fails on AMS CI. > The CI is a bit slower and it seems the issue consists of timeout handling. > {code} > [INFO] Running org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 57.021 s <<< FAILURE! - in org.eclipse.microprofile.lra.tck.TckRecoveryTests > [ERROR] testCancelWhenParticipantIsUnavailable(org.eclipse.microprofile.lra.tck.TckRecoveryTests) Time elapsed: 28.349 s <<< FAILURE! > java.lang.AssertionError: Compensate on restarted service should have been called. Was -1 expected:<200> but was:<500> > at org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable(TckRecoveryTests.java:215) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3326) Nested participant AfterLRA call in complete scenario should be postponed until the parent LRA completes/compensates

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3326?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3326: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Nested participant AfterLRA call in complete scenario should be postponed until the parent LRA completes/compensates > -------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3326 > URL: https://issues.redhat.com/browse/JBTM-3326 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > Currently, the nested participant enters the H_H state after it completes and the recovery calls the after LRA method in the first pass. This call should be postponed until the parent LRA finishes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 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 June 2020