August 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3341) Failed LRA is not kept in FailedTo* state in the object store

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3341?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3341: ----------------------------------- Fix Version/s: 5.next > Failed LRA is not kept in FailedTo* state in the object store > ------------------------------------------------------------- > > Key: JBTM-3341 > URL: https://issues.redhat.com/browse/JBTM-3341 > 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 > > > when executing {{TckContextTests#testStatus,TckContextTests#testForget}} one after another the LRA started in testForget is kept in Closing state in object store even when it's removed from the in memory LRA lists. When the testStatus invokes recovery this LRA is also recovered (because it's still in Closing state) and then it's kept even in the in memory recovery list and again displayed to users. The testForget LRA is finished with failing participant (returning FailedToComplete) and the second phase correctly returns FINISH_ERROR, however, this change needs to be also reflected in the state of the parent Transaction object. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

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

by Anonymous (Jira)

[ https://issues.redhat.com/browse/JBTM-3350?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Mayank Kunwar created pull request #292 in GitHub ------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Upgrade jca + hibernate quickstart (org.jboss.narayana.quickstarts:jca-and-hibernate) > ------------------------------------------------------------------------------------- > > Key: JBTM-3350 > URL: https://issues.redhat.com/browse/JBTM-3350 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Reporter: Mayank Kunwar > Assignee: Mayank Kunwar > Priority: Blocker > Fix For: 5.next > > > The jca + hibernate quickstart is using a very old version of ironjacamar (org.jboss.ironjacamar:1.1.0.Beta5) and needs updating to use a more recent release. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3351) clearHeuristic management operation should clear participant's heuristic flag as well as it clears the transaction heuristic flag

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3351?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3351: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > clearHeuristic management operation should clear participant's heuristic flag as well as it clears the transaction heuristic flag > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3351 > URL: https://issues.redhat.com/browse/JBTM-3351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration, Transaction Core > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > The management operation {{clearHeuristic}} should consider to clear heuristic flag not only from the transaction ({{BasicAction}}) but from the participant record as well - when possible, e.g. the XA resource record maintains heuristic flag for participant and thus it should be cleared on the operation. > The current management operation {{'clearHeuristic'}} is invoked only on the "covering" transaction - {{BasicAction}} is modified[1] -> [2] -> [3]. But the {{XAResourceRecord}} heuristics state[4] is unchanged. Then during recovery commit retry the {{XAResource.commit}} is denied[5]. > [1] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [2] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [3] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [4] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaJTA/jta/class... > [5] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaJTA/jta/class... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3355) Harmonize usage of the DTO objects in LRA codebase

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3355?page=com.atlassian.jira.plugin... ] Work on JBTM-3355 started by Ondrej Chaloupka. ---------------------------------------------- > Harmonize usage of the DTO objects in LRA codebase > -------------------------------------------------- > > Key: JBTM-3355 > URL: https://issues.redhat.com/browse/JBTM-3355 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > In the current LRA codebase there are use 2 separate DTO objects for transfering the LRA state. > * https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-coordin... > * https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-coordin... > They are used in the same meaning and they duplicate each other. There needs to be used only one to clean the purpose. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3355) Harmonize usage of the DTO objects in LRA codebase

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3355?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3355: ----------------------------------- Summary: Harmonize usage of the DTO objects in LRA codebase (was: Harmonize usage of the DTO objects in the LRA codebase) > Harmonize usage of the DTO objects in LRA codebase > -------------------------------------------------- > > Key: JBTM-3355 > URL: https://issues.redhat.com/browse/JBTM-3355 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > In the current LRA codebase there are use 2 separate DTO objects for transfering the LRA state. > * https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-coordin... > * https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-coordin... > They are used in the same meaning and they duplicate each other. There needs to be used only one to clean the purpose. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3355) Harmonize usage of the DTO objects in the LRA codebase

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3355: -------------------------------------- Summary: Harmonize usage of the DTO objects in the LRA codebase Key: JBTM-3355 URL: https://issues.redhat.com/browse/JBTM-3355 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.10.5.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka In the current LRA codebase there are use 2 separate DTO objects for transfering the LRA state. * https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-coordin... * https://github.com/jbosstm/narayana/blob/5.10.5.Final/rts/lra/lra-coordin... They are used in the same meaning and they duplicate each other. There needs to be used only one to clean the purpose. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3343) Integration LRA tests need to be runnable on all runtimes

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3343?page=com.atlassian.jira.plugin... ] Work on JBTM-3343 started by Ondrej Chaloupka. ---------------------------------------------- > Integration LRA tests need to be runnable on all runtimes > --------------------------------------------------------- > > Key: JBTM-3343 > URL: https://issues.redhat.com/browse/JBTM-3343 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Critical > Fix For: 5.next > > > The LRA integration testing is currently split to two parts. The Narayana byteman recovery testing is run only with WildFly runtime while the TCK and other integration tests are run with combination of Qurakus/Thorntail. > The goal of this issue is to change the structure of the LRA integration tests to run with all available runtimes. Currently we have Quarkus, WildFly and Thorntail. > The integration tests need be runnable against the all runtimes. > NOTE: The Thorntail is eprecated and will be removed from the LRA. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3351) clearHeuristic management operation should clear participant's heuristic flag as well as it clears the transaction heuristic flag

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3351?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on JBTM-3351 at 8/7/20 11:27 AM: ----------------------------------------------------------------- After the discussion with [~mmusgrov] it's clear that the `:recover` call from WildFly jboss-cli.sh which invokes the `clearHeuristic` should make changes for the participant record if needed. Every record has to imlement that functionality as it inherits from `AbastractRecord`. For `XAResourceRecord` the record is marked with `_heuristic` The operation to be used is the `AbstractRecord#forgetHeuristic`. The `XAResourcRecorde#forgetHeuristic` cleans the `_heuristc` flag, it calls `XAResource.forget(Xid)` and it removes the connection to the XAResource. But neither of later two is an issue as the `XAResource` ignores the `forget(Xid)` call if the transaction is not heuristically finished (by XA spec) and the connection is no more needed as the recovery will re-create the connection to the resource if neeeded. If the XAResource transaction is not heuristically finished then the forget(Xid) call is ignored by RM. In such case the recovery may retry the attempt and it's ok. If the XAREsource was heuristically finished then there is no way to succesfully retry the transaction. For `:recover` works the XAResourceRecord needs to be reactivated and replayed by recovery manager. The operation of `forgetHeuristic` clears the problematic flag and let the next recovery cycle to retry the attempt. was (Author: ochaloup): After the discussion with [~mmusgrov] it's clear that the `:recover` call from WildFly jboss-cli.sh which invokes the `clearHeuristic` should make changes for the participant record marked with `_heuristic` It could be used the `AbstractRecord#forgetHeuristic`. The `XAResource#forgetHeuristic`does some more things as it calls `XAResource.forget(Xid)` and it removes the connection to the XAResource. But neither of two is an issue as the `XAResource` ignores the `forget(Xid)` call if the transaction is not heuristically finished (by XA spec) and the connection is no more needed as the recovery will re-create the connection to the resource if neeeded. If the XAResource transaction is not heuristically finished then the forget(Xid) call is ignored by RM. In such case the recovery may retry the attempt and it's ok. If the XAREsource was heuristically finished then there is no way to succesfully retry the transaction. For `:recover` works the XAResourceRecord needs to be reactivated and replayed by recovery manager. The operation of `forgetHeuristic` clears the problematic flag and let the next recovery cycle to retry the attempt. > clearHeuristic management operation should clear participant's heuristic flag as well as it clears the transaction heuristic flag > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3351 > URL: https://issues.redhat.com/browse/JBTM-3351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration, Transaction Core > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The management operation {{clearHeuristic}} should consider to clear heuristic flag not only from the transaction ({{BasicAction}}) but from the participant record as well - when possible, e.g. the XA resource record maintains heuristic flag for participant and thus it should be cleared on the operation. > The current management operation {{'clearHeuristic'}} is invoked only on the "covering" transaction - {{BasicAction}} is modified[1] -> [2] -> [3]. But the {{XAResourceRecord}} heuristics state[4] is unchanged. Then during recovery commit retry the {{XAResource.commit}} is denied[5]. > [1] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [2] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [3] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [4] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaJTA/jta/class... > [5] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaJTA/jta/class... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3351) clearHeuristic management operation should clear participant's heuristic flag as well as it clears the transaction heuristic flag

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3351?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3351: ---------------------------------------- After the discussion with [~mmusgrov] it's clear that the `:recover` call from WildFly jboss-cli.sh which invokes the `clearHeuristic` should make changes for the participant record marked with `_heuristic` It could be used the `AbstractRecord#forgetHeuristic`. The `XAResource#forgetHeuristic`does some more things as it calls `XAResource.forget(Xid)` and it removes the connection to the XAResource. But neither of two is an issue as the `XAResource` ignores the `forget(Xid)` call if the transaction is not heuristically finished (by XA spec) and the connection is no more needed as the recovery will re-create the connection to the resource if neeeded. If the XAResource transaction is not heuristically finished then the forget(Xid) call is ignored by RM. In such case the recovery may retry the attempt and it's ok. If the XAREsource was heuristically finished then there is no way to succesfully retry the transaction. For `:recover` works the XAResourceRecord needs to be reactivated and replayed by recovery manager. The operation of `forgetHeuristic` clears the problematic flag and let the next recovery cycle to retry the attempt. > clearHeuristic management operation should clear participant's heuristic flag as well as it clears the transaction heuristic flag > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3351 > URL: https://issues.redhat.com/browse/JBTM-3351 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration, Transaction Core > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The management operation {{clearHeuristic}} should consider to clear heuristic flag not only from the transaction ({{BasicAction}}) but from the participant record as well - when possible, e.g. the XA resource record maintains heuristic flag for participant and thus it should be cleared on the operation. > The current management operation {{'clearHeuristic'}} is invoked only on the "covering" transaction - {{BasicAction}} is modified[1] -> [2] -> [3]. But the {{XAResourceRecord}} heuristics state[4] is unchanged. Then during recovery commit retry the {{XAResource.commit}} is denied[5]. > [1] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [2] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [3] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaCore/arjuna/c... > [4] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaJTA/jta/class... > [5] https://github.com/jbosstm/narayana/blob/5.10.5.Final/ArjunaJTA/jta/class... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3352) Remove "effectivellyActive" and deprecated status endpoints from the LRA Coordinator API

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3352?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3352: ----------------------------------- Fix Version/s: 5.next > Remove "effectivellyActive" and deprecated status endpoints from the LRA Coordinator API > ---------------------------------------------------------------------------------------- > > Key: JBTM-3352 > URL: https://issues.redhat.com/browse/JBTM-3352 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > The LRA Coordinator API contains the no more used and misguiding flag "effectivelyActive" for the `/status` API method. This should be removed to clean the API. > At the same time the API contains API method of "isActive" returning the Active status for LRA. This duplicates the functionality of the `status` endpoint and it's not needed. The API should be cleand from it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 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 August 2020