November 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3224) Wrong formatting of error message when object store can't be initialized

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3224?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondrej Chaloupka created pull request #1532 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Wrong formatting of error message when object store can't be initialized > ------------------------------------------------------------------------ > > Key: JBTM-3224 > URL: https://issues.jboss.org/browse/JBTM-3224 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.10.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > There is a wrong formatting of error message for init error of object store. This is output currently: > {code} > Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012391: Could not initialize object store {0} of type {1} > at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:160) > at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.getActionStore(StoreManager.java:111) > at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.getRecoveryStore(StoreManager.java:68) > {code} > Coming from: > https://github.com/jbosstm/narayana/blob/5.10.0.Final/ArjunaCore/arjuna/c... > Desired state is to get the store and type to be printed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3224) Wrong formatting of error message when object store can't be initialized

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3224?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3224: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1532 > Wrong formatting of error message when object store can't be initialized > ------------------------------------------------------------------------ > > Key: JBTM-3224 > URL: https://issues.jboss.org/browse/JBTM-3224 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.10.0.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > There is a wrong formatting of error message for init error of object store. This is output currently: > {code} > Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012391: Could not initialize object store {0} of type {1} > at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:160) > at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.getActionStore(StoreManager.java:111) > at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.getRecoveryStore(StoreManager.java:68) > {code} > Coming from: > https://github.com/jbosstm/narayana/blob/5.10.0.Final/ArjunaCore/arjuna/c... > Desired state is to get the store and type to be printed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3224) Wrong formatting of error message when object store can't be initialized

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3224: -------------------------------------- Summary: Wrong formatting of error message when object store can't be initialized Key: JBTM-3224 URL: https://issues.jboss.org/browse/JBTM-3224 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Affects Versions: 5.10.0.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka There is a wrong formatting of error message for init error of object store. This is output currently: {code} Caused by: com.arjuna.ats.arjuna.exceptions.FatalError: ARJUNA012391: Could not initialize object store {0} of type {1} at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:160) at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.getActionStore(StoreManager.java:111) at org.jboss.jts//com.arjuna.ats.arjuna.objectstore.StoreManager.getRecoveryStore(StoreManager.java:68) {code} Coming from: https://github.com/jbosstm/narayana/blob/5.10.0.Final/ArjunaCore/arjuna/c... Desired state is to get the store and type to be printed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3223) Validate LRA behaviour when multiple LRA's are active on the same thread

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3223: -------------------------------------- Summary: Validate LRA behaviour when multiple LRA's are active on the same thread Key: JBTM-3223 URL: https://issues.jboss.org/browse/JBTM-3223 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Affects Versions: 5.10.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Add tests that check that when multiple LRA's are active on the same thread that as one LRA finishes that: - the next one is handled correctly - creating another one still works fine This issues relates to some suspect code at the end of the method `NarayanaLRAClient#endLRA` where the base URI of the target coordinator includes the Uid part of the LRA id. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3222) Local LRA lookup should just use the Uid part of the LRA

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3222: -------------------------------------- Summary: Local LRA lookup should just use the Uid part of the LRA Key: JBTM-3222 URL: https://issues.jboss.org/browse/JBTM-3222 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The LRA implementation identifies LRA's by their full JAX-RS resource path (aka URI). [Remark we use the full resource path in order to determine which host owns the LRA]. But when these URI's are calculated sometimes the base URI ends up as localhost and other times as 127.0.0.1 (or :1). The code in the coordinator that wants to know if it owns an LRA should avoid checking the whole path and instead just rely on the Uid part of the resource path (com.arjuna.ats.arjuna.common.Uid). This is safe since the URI is globally unique. Note that this technique only works for LRA ids created by narayana which is fine because the code that does the lookup is only interested in whether the local coordinator created the LRA (tangentially related but it is also noteworthy that we are not targeting interoperability in LRA version 1.0 The particular code that does the lookup is in LRAService#getTransaction(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3221) Refactor NarayanaLRARecovery according to the specification upgrades

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/JBTM-3221?page=com.atlassian.jira.plugin.... ] Martin Stefanko updated JBTM-3221: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1531 > Refactor NarayanaLRARecovery according to the specification upgrades > -------------------------------------------------------------------- > > Key: JBTM-3221 > URL: https://issues.jboss.org/browse/JBTM-3221 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > Refactor the NarayanaLRARecovery according to the spec changes in [LRA issue 249|https://github.com/eclipse/microprofile-lra/issues/249]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JBTM-3221) Refactor NarayanaLRARecovery according to the specification upgrades

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3221: ------------------------------------- Summary: Refactor NarayanaLRARecovery according to the specification upgrades Key: JBTM-3221 URL: https://issues.jboss.org/browse/JBTM-3221 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.0.Final Reporter: Martin Stefanko Assignee: Martin Stefanko Refactor the NarayanaLRARecovery according to the spec changes in [LRA issue 249|https://github.com/eclipse/microprofile-lra/issues/249]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

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: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > 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 > Fix For: 5.next > > > 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

1
0
0 / 0

[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 commented on JBTM-3212: ---------------------------------------- I have marked it as a blocker as it blocks the feature but removed the fix version as it does not block releasing Narayana > 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: Blocker > > 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

1
0
0 / 0

[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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2019