November 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3212) Ensure that an LRA timeout timer is restarted after a crash

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3212?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3212: ----------------------------------- Fix Version/s: (was: 5.next) > Ensure that an LRA timeout timer is restarted after a crash > ----------------------------------------------------------- > > Key: JBTM-3212 > URL: https://issues.jboss.org/browse/JBTM-3212 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > > LRAs can be timed out. After a crash the time should be restarted. Currently this functionality is marked as a TODO item: > > https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... > and > https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3219) Upgrade the RESTEasy dependency to 3.9.1.Final (which matches what WFLY is using)

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3219?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3219: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade the RESTEasy dependency to 3.9.1.Final (which matches what WFLY is using) > --------------------------------------------------------------------------------- > > Key: JBTM-3219 > URL: https://issues.jboss.org/browse/JBTM-3219 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Affects Versions: 5.10.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > [WFLY-12786] (Upgrade RESTEasy to 3.9.1.Final) is upgrading its RESTEasy dependency. Since we need to align with WFLY and since we are still on an old beta (from Sept 2016) we should upgrade. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3220) LRA branch failures

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3220: -------------------------------------- Summary: LRA branch failures Key: JBTM-3220 URL: https://issues.jboss.org/browse/JBTM-3220 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA, Testing Affects Versions: 5.10.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.10.0.Final TckContextTests.testForget:154 testForget resource status should have been called expected:<1> but was:<2> seems to fail consistently on the narayana LRA branch but it works fine on the Narayana master. I would recommend that we use this JIRA to capture any further CI LRA tck test failures. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3219) Upgrade the RESTEasy dependency to 3.9.1.Final (which matches what WFLY is using)

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3219?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-3219: ---------------------------------------- We should also ensure that the versions of RESTEasy and jaxrs-api are consistent. > Upgrade the RESTEasy dependency to 3.9.1.Final (which matches what WFLY is using) > --------------------------------------------------------------------------------- > > Key: JBTM-3219 > URL: https://issues.jboss.org/browse/JBTM-3219 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Affects Versions: 5.10.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > [WFLY-12786] (Upgrade RESTEasy to 3.9.1.Final) is upgrading its RESTEasy dependency. Since we need to align with WFLY and since we are still on an old beta (from Sept 2016) we should upgrade. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3218) Transaction statistics for read-only + last record may go wrong

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3218?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3218: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1528 > Transaction statistics for read-only + last record may go wrong > --------------------------------------------------------------- > > Key: JBTM-3218 > URL: https://issues.jboss.org/browse/JBTM-3218 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.10.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > As discussed at https://issues.jboss.org/browse/WFTC-78?focusedCommentId=13808486#comment... there was seen a wrong statistics being reported at a remote ejb calls for WFLY. The number of committed transactions went bigger than the number of all processed transactions. > This happens when the transaction consists of {{XAResource}} which announces to be read only during {{prepare}} call and with the second resource which is {{LastResource}} (https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/jav...). > In such case the {{onePhaseCommit}} could be called during the {{BasicAction#prepare}} call (https://github.com/jbosstm/narayana/blob/5.10.0.Final/ArjunaCore/arjuna/c...). > In such case the statistics of committed transactions are increased during the {{onePhaseCommit}} method call and then during the {{phase2Commit}} at {{BasicAction#End}} call (https://github.com/jbosstm/narayana/blob/5.10.0.Final/ArjunaCore/arjuna/c...). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3163: ----------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: https://github.com/jbosstm/narayana/pull/1468 > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > 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)

5 years, 3 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.... ] Michael Musgrove reassigned JBTM-3163: -------------------------------------- Assignee: Michael Musgrove (was: Martin Stefanko) > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/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)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3186) Safeguard LRA filters for situations when CDI is not available

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3186?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson closed JBTM-3186. ---------------------------------- > Safeguard LRA filters for situations when CDI is not available > --------------------------------------------------------------- > > Key: JBTM-3186 > URL: https://issues.jboss.org/browse/JBTM-3186 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.10.0.Final > > > When CDI is not available in LRA microservice, following exception is thrown: > {code:java} > Caused by: java.lang.NullPointerException > at io.narayana.lra.filter.ServerLRAFilter.filter(ServerLRAFilter.java:311) > {code} > This is thrown because CDI is not available in the container. The check for null injection can prohibit this behavior and LRA can still function for REST-based services in case CDI is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3184) LRA TckParticipantTests do not finish started LRAs

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3184?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3184: ----------------------------------- Fix Version/s: 5.10.0.Final > LRA TckParticipantTests do not finish started LRAs > -------------------------------------------------- > > Key: JBTM-3184 > URL: https://issues.jboss.org/browse/JBTM-3184 > 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.10.0.Final > > > Running TckParticipantTests leaves 4 open LRAs which will never be finished. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3184) LRA TckParticipantTests do not finish started LRAs

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3184?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson closed JBTM-3184. ---------------------------------- > LRA TckParticipantTests do not finish started LRAs > -------------------------------------------------- > > Key: JBTM-3184 > URL: https://issues.jboss.org/browse/JBTM-3184 > 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.10.0.Final > > > Running TckParticipantTests leaves 4 open LRAs which will never be finished. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2019