June 2020 - jbossts-issues - Jboss List Archives

[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: ---------------------------------------- The fix was based on a bit hacky reflection manipulation where there is added a hook to CDI extension which go through annotations of the defined classes and it directly changes the {{timeLimit}} value of the annotation class itself. When the annotation class is then used by LRA filter it gets the changed class with adjusted timeout. > 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)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3325) Create a way to close XAResource at the end of the recovery cycle processing

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3325?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3325: ---------------------------------------- I'm leaving this task for further discussion as there is currently no resolution found based on the https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topi... I would need more details from [~lbarreiro] what are his expectations about integration. >From what [~jhalliday] explained the call of {{XAResource.recover(TMENDRSCAN)}} does not mean there is no more work done with the XAResource. The recovery modules can share the {{XAResource}} and when the {{XARecoveryModule}} finishes its work there still could be other modules touching the resource. If the {{TMENDRSCAN}} means closing the underlaying connection it could mean the following module fails to do its work as the XAResource is already "closed". Some different approach like some hook for the end of the recovery cycle could be considered but currently it's not clear to me if it's what is needed. > Create a way to close XAResource at the end of the recovery cycle processing > ---------------------------------------------------------------------------- > > Key: JBTM-3325 > URL: https://issues.redhat.com/browse/JBTM-3325 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > From discussions about Narayana integration to Agroal (https://agroal.github.io/) there came an idea how to make easier for Agroal to integrate with Narayana recovery processing. > Usually (or at least Agroal does so) the brand new {{XAResource}} is provided from the call of the {{XAResourceRecovery}} (https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/mai...). > aka. Agroal implements the {{XAResourceRecovery}} and register it with the Narayana with adding it to with https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/mai... to be used in {{XARecoveryModule}}. > When the periodic recovery cycle ends the {{XAResource}} is not used (next time the recovery processing calls the {{XAResourceRecovery#getXAResources()}} to get the resource for scanning again). The transaction manager announces that the scan ended with call {{XAResource.recover(XAResource.TMENDRSCAN)}} (this is an internal to how Narayana works). > It would be beneficial provide an option that Narayana closes {{XAResource}}s at the end of the recovery cycle when Narayana does not plan to use it again. > The idea is to check if the {{XAResource}} is {{AutoCloseable}} and if so then the {{XAResource}} is closed at the end of the recovery cycle processing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3325) Create a way to close XAResource at the end of the recovery cycle processing

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3325?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3325: ----------------------------------- Status: Open (was: Pull Request Sent) No appropriate solution which consider all the code paths. > Create a way to close XAResource at the end of the recovery cycle processing > ---------------------------------------------------------------------------- > > Key: JBTM-3325 > URL: https://issues.redhat.com/browse/JBTM-3325 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > From discussions about Narayana integration to Agroal (https://agroal.github.io/) there came an idea how to make easier for Agroal to integrate with Narayana recovery processing. > Usually (or at least Agroal does so) the brand new {{XAResource}} is provided from the call of the {{XAResourceRecovery}} (https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/mai...). > aka. Agroal implements the {{XAResourceRecovery}} and register it with the Narayana with adding it to with https://github.com/jbosstm/jboss-transaction-spi/blob/7.6.0.Final/src/mai... to be used in {{XARecoveryModule}}. > When the periodic recovery cycle ends the {{XAResource}} is not used (next time the recovery processing calls the {{XAResourceRecovery#getXAResources()}} to get the resource for scanning again). The transaction manager announces that the scan ended with call {{XAResource.recover(XAResource.TMENDRSCAN)}} (this is an internal to how Narayana works). > It would be beneficial provide an option that Narayana closes {{XAResource}}s at the end of the recovery cycle when Narayana does not plan to use it again. > The idea is to check if the {{XAResource}} is {{AutoCloseable}} and if so then the {{XAResource}} is closed at the end of the recovery cycle processing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3333) Use Artemis object store in the ArjuraJTA/object_store quickstart.

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3333?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3333: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Use Artemis object store in the ArjuraJTA/object_store quickstart. > ------------------------------------------------------------------ > > Key: JBTM-3333 > URL: https://issues.redhat.com/browse/JBTM-3333 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Miloslav Žežulka > Assignee: Miloslav Žežulka > Priority: Minor > Fix For: 5.next > > > After resolving a bug in Narayana itself, we can now use the Artemis object store in the [quickstart showcasing object store usage|https://github.com/jbosstm/quickstart/tree/master/ArjunaJTA/object_...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3334) Fix XTS quickstart to compile WFLY 20 quickstarts correctly

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3334?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3334: ----------------------------------- Affects Version/s: 5.10.5.Final > Fix XTS quickstart to compile WFLY 20 quickstarts correctly > ----------------------------------------------------------- > > Key: JBTM-3334 > URL: https://issues.redhat.com/browse/JBTM-3334 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > The current XTS quickstart (https://github.com/jbosstm/quickstart/tree/5.10.5.Final/XTS) fails because there is used WFLY 20 quickstarts which was changed and start providing a microprofile quickstart which expects microprofile dependencies to be defined. > The XTS quickstarts need to add `version.microprofile.bom` property to compile correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3334) Fix XTS quickstart to compile WFLY 20 quickstarts correctly

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3334?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3334: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next (was: 5.10.5.Final) Resolution: Done > Fix XTS quickstart to compile WFLY 20 quickstarts correctly > ----------------------------------------------------------- > > Key: JBTM-3334 > URL: https://issues.redhat.com/browse/JBTM-3334 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > The current XTS quickstart (https://github.com/jbosstm/quickstart/tree/5.10.5.Final/XTS) fails because there is used WFLY 20 quickstarts which was changed and start providing a microprofile quickstart which expects microprofile dependencies to be defined. > The XTS quickstarts need to add `version.microprofile.bom` property to compile correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3335) Upgrade jca + tomcat quickstart (org.jboss.narayana.quickstarts:jca-and-tomcat)

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3335: -------------------------------------- Summary: Upgrade jca + tomcat quickstart (org.jboss.narayana.quickstarts:jca-and-tomcat) Key: JBTM-3335 URL: https://issues.redhat.com/browse/JBTM-3335 Project: JBoss Transaction Manager Issue Type: Bug Components: Quickstarts Reporter: Michael Musgrove The jca + tomcat quickstart is using a very old version of hibernate-validator (org.hibernate:hibernate-validator:5.0.1.Final) and needs updating to use a more recent release. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3334) Fix XTS quickstart to compile WFLY 20 quickstarts correctly

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3334?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3334: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/287 > Fix XTS quickstart to compile WFLY 20 quickstarts correctly > ----------------------------------------------------------- > > Key: JBTM-3334 > URL: https://issues.redhat.com/browse/JBTM-3334 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.10.5.Final > > > The current XTS quickstart (https://github.com/jbosstm/quickstart/tree/5.10.5.Final/XTS) fails because there is used WFLY 20 quickstarts which was changed and start providing a microprofile quickstart which expects microprofile dependencies to be defined. > The XTS quickstarts need to add `version.microprofile.bom` property to compile correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3334) Fix XTS quickstart to compile WFLY 20 quickstarts correctly

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3334: -------------------------------------- Summary: Fix XTS quickstart to compile WFLY 20 quickstarts correctly Key: JBTM-3334 URL: https://issues.redhat.com/browse/JBTM-3334 Project: JBoss Transaction Manager Issue Type: Bug Components: Quickstarts Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka Fix For: 5.10.5.Final The current XTS quickstart (https://github.com/jbosstm/quickstart/tree/5.10.5.Final/XTS) fails because there is used WFLY 20 quickstarts which was changed and start providing a microprofile quickstart which expects microprofile dependencies to be defined. The XTS quickstarts need to add `version.microprofile.bom` property to compile correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3307) LRACoordinatorRecovery2TestCase regularly fails on CI

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3307?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3307: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1614 > LRACoordinatorRecovery2TestCase regularly fails on CI > ----------------------------------------------------- > > Key: JBTM-3307 > URL: https://issues.redhat.com/browse/JBTM-3307 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Ondrej Chaloupka > Priority: Blocker > > The test regularly fails CI > [ERROR] testRecovery2(io.narayana.lra.coordinator.LRACoordinatorRecovery2TestCase) Time elapsed: 30.455 s <<< FAILURE! > java.lang.AssertionError: LRA with short timeout should not be active > presumably due to a timing issue (since I cannot reproduce it on my laptop). I will see if there is a way to make the test more robust. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

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