October 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3074) No test cleanup for STM taxonomy tests

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3074: ----------------------------------- Description: The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. (was: The tests added by JBTM-3063 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. ) > No test cleanup for STM taxonomy tests > --------------------------------------- > > Key: JBTM-3074 > URL: https://issues.jboss.org/browse/JBTM-3074 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Priority: Major > Attachments: stm.dump > > > The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3074) No test cleanup for STM taxonomy tests

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3074?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3074: ----------------------------------- Attachment: stm.dump > No test cleanup for STM taxonomy tests > --------------------------------------- > > Key: JBTM-3074 > URL: https://issues.jboss.org/browse/JBTM-3074 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Priority: Major > Attachments: stm.dump > > > The tests added by JBTM-3058 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3074) No test cleanup for STM taxonomy tests

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3074: -------------------------------------- Summary: No test cleanup for STM taxonomy tests Key: JBTM-3074 URL: https://issues.jboss.org/browse/JBTM-3074 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Michael Musgrove The tests added by JBTM-3063 are missing clean up actions . Some of the tests launch new threads and if they hang on one test they may cause subsequent tests to hang resulting in a stalled CI run (see attached file for an example). The after test clean up should report the failures and then clean up so that subsequent tests can execute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3073) Do not mandate JAX-RS annotations on @Compensate/@Complete methods

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3073: -------------------------------------- Summary: Do not mandate JAX-RS annotations on @Compensate/@Complete methods Key: JBTM-3073 URL: https://issues.jboss.org/browse/JBTM-3073 Project: JBoss Transaction Manager Issue Type: Feature Request Components: LRA Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Cloned from [https://github.com/eclipse/microprofile-lra/issues/35|http://example.com]: It is up to the implementation on how the Compensate methods are called. This could be through JAX-RS calls but this should not be the only way (although an implementation will probably only implement one method). This makes it easier to use the 'events' way of coordination. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2997) Ensure that any LRA coordinator instance can control any LRA

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka reassigned JBTM-2997: ------------------------------------- Assignee: Ondra Chaloupka (was: Michael Musgrove) > Ensure that any LRA coordinator instance can control any LRA > ------------------------------------------------------------ > > Key: JBTM-2997 > URL: https://issues.jboss.org/browse/JBTM-2997 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.8.0.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.later > > > Currently the management of an LRA is restricted to the coordinator that created it. It would be preferable to have the option of allowing any coordinator be able to manage any LRA. The motivation for this feature is to enhance the usability of LRAs in cloud based environments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2997) Ensure that any LRA coordinator can control any LRA

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2997: -------------------------------- Forum Reference: https://docs.google.com/document/d/1OUyn-33LNKbeQkJJirusgWgm2FKXdf6vRJHiU... > Ensure that any LRA coordinator can control any LRA > --------------------------------------------------- > > Key: JBTM-2997 > URL: https://issues.jboss.org/browse/JBTM-2997 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.8.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > Currently the management of an LRA is restricted to the coordinator that created it. It would be preferable to have the option of allowing any coordinator be able to manage any LRA. The motivation for this feature is to enhance the usability of LRAs in cloud based environments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2997) Ensure that any LRA coordinator instance can control any LRA

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2997: -------------------------------- Summary: Ensure that any LRA coordinator instance can control any LRA (was: Ensure that any LRA coordinator can control any LRA) > Ensure that any LRA coordinator instance can control any LRA > ------------------------------------------------------------ > > Key: JBTM-2997 > URL: https://issues.jboss.org/browse/JBTM-2997 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.8.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > Currently the management of an LRA is restricted to the coordinator that created it. It would be preferable to have the option of allowing any coordinator be able to manage any LRA. The motivation for this feature is to enhance the usability of LRAs in cloud based environments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2997) Ensure that any LRA coordinator can control any LRA

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Michael Musgrove edited comment on JBTM-2997 at 10/29/18 8:14 AM: ------------------------------------------------------------------ Here are some notes I added about different coordinators accessing the same LRA record: Up until the time that the state moves to Compensating/Compensated anyone should be able to update an LRA record. After that we need to assign an owner (ie the coordinator that is driving the termination phase) and there needs to be a component that monitors that owners progress (assigning a new owner if it it fails). I don't think we need to worry about things like network partitions since the participant callbacks are meant to be idempotent. In recovery scenarios I would just write a timestamp into the record on each recovery pass and monitor that. In fact the presence of that timestamp would imply that there is a current owner and other coordinators need to leave it alone and only take over if it stops being updated. Note that before the end phase starts any coordinator is allowed to update the (shared) log and we should definitely consider LockReccord/STM for that purpose. To reiterate, an owner is assigned only when the termination phase of the protocol starts. If any another coordinator sees that the LRA is owned it should monitor the progress and if it sees that the current owner is not updating the timestamp it should (forcibly) takes ownership of the LRA. Furthermore, since an owner is assigned only when the end phase begins there should be no more join requests nor close or cancel requests and if there are then any coordinator can return an error back to the requester. We could also consider writing the owners id into the log as well as the timestamp to avoid potential race conditions. was (Author: mmusgrov): Here are some notes I added about different coordinators accessing the same LRA record: Up until the time that the state moves to Compensating/Compensated anyone should be able to update an LRA record. After that we need to assign an owner (ie the coordinator that is driving the termination phase) and there needs to be a component that monitors that owners progress (assigning a new owner if it it fails). I don't think we need to worry about things like network partitions since the participant callbacks are meant to be idempotent. In recovery scenarios I would just write a timestamp into the record on each recovery pass and monitor that. In fact the presence of that timestamp would imply that there is a current owner and other coordinators need to leave it alone and only take over if it stops being updated. Since STM/LockRecords ought to work for all store types I think we should definitely consider their use. > Ensure that any LRA coordinator can control any LRA > --------------------------------------------------- > > Key: JBTM-2997 > URL: https://issues.jboss.org/browse/JBTM-2997 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.8.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > Currently the management of an LRA is restricted to the coordinator that created it. It would be preferable to have the option of allowing any coordinator be able to manage any LRA. The motivation for this feature is to enhance the usability of LRAs in cloud based environments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2997) Ensure that any LRA coordinator can control any LRA

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Michael Musgrove edited comment on JBTM-2997 at 10/29/18 7:39 AM: ------------------------------------------------------------------ Here are some notes I added about different coordinators accessing the same LRA record: Up until the time that the state moves to Compensating/Compensated anyone should be able to update an LRA record. After that we need to assign an owner (ie the coordinator that is driving the termination phase) and there needs to be a component that monitors that owners progress (assigning a new owner if it it fails). I don't think we need to worry about things like network partitions since the participant callbacks are meant to be idempotent. In recovery scenarios I would just write a timestamp into the record on each recovery pass and monitor that. In fact the presence of that timestamp would imply that there is a current owner and other coordinators need to leave it alone and only take over if it stops being updated. Since STM/LockRecords ought to work for all store types I think we should definitely consider their use. was (Author: mmusgrov): Here are some notes I added about different coordinators accessing the same LRA record: Up until the time that the state moves to Compensating/Compensated anyone should be able to update an LRA record. After that we need to assign an owner (ie the coordinator that is driving the termination phase) and there needs to be a component that monitors that owners progress (assigning a new owner if it it fails). I don't think we need to worry about things like network partitions since the participant callbacks are meant to be idempotent. In recovery scenarios I would just write a timestamp into the record on each recovery pass and monitor that. In fact the presence of that timestamp would imply that there is a current owner and other coordinators need to leave it alone and only take over if it stops being updated. To summarise, I would just write the owner/timestamp into the record when the state change is written and periodically update it thereafter. Any other coordinator that gets a request to close/cancel the LRA (this includes period recovery) should only take control if the owner/timestamp stops being updated. Since STM/LockRecords ought to work for all store types I think we should definitely consider their use. > Ensure that any LRA coordinator can control any LRA > --------------------------------------------------- > > Key: JBTM-2997 > URL: https://issues.jboss.org/browse/JBTM-2997 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.8.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.later > > > Currently the management of an LRA is restricted to the coordinator that created it. It would be preferable to have the option of allowing any coordinator be able to manage any LRA. The motivation for this feature is to enhance the usability of LRAs in cloud based environments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2824) Check that the changes for JDK-9 support still build with JDK-8

by Amos Feng (Jira)

[ https://issues.jboss.org/browse/JBTM-2824?page=com.atlassian.jira.plugin.... ] Amos Feng resolved JBTM-2824. ----------------------------- Fix Version/s: 5.next (was: 5.later) Resolution: Done > Check that the changes for JDK-9 support still build with JDK-8 > --------------------------------------------------------------- > > Key: JBTM-2824 > URL: https://issues.jboss.org/browse/JBTM-2824 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.later > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Critical > Fix For: 5.next > > > JBTM-2685 is adding support for building with the JDK-9 compiler using branch https://github.com/jbosstm/narayana/tree/jdk9-experimental > This JIRA is for reporting when the branch fails to build on JDK-8 (currently it is failing because the build is not producing the jar artefact for org.jboss.narayana.jts:narayana-jts-idlj). See CI job http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-9-jdk-8 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 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 October 2018