July 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3342) LRA annotated method should expose the parent context header

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3342?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3342: ----------------------------------- Priority: Blocker (was: Major) > LRA annotated method should expose the parent context header > ------------------------------------------------------------ > > Key: JBTM-3342 > URL: https://issues.redhat.com/browse/JBTM-3342 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > When a method annotated with @LRA is invoked with a nested context the parent context should be made available to the invoked method via the [LRA_HTTP_ENDED_CONTEXT_HEADER|http://example.com/] http header. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3346) Journal store file count grows unbounded

by Anonymous (Jira)

[ https://issues.redhat.com/browse/JBTM-3346?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when jhalliday created pull request #1651 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Journal store file count grows unbounded > ---------------------------------------- > > Key: JBTM-3346 > URL: https://issues.redhat.com/browse/JBTM-3346 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.10.5.Final > Reporter: Jonathan Halliday > Assignee: Jonathan Halliday > Priority: Minor > > Under sustained high load the HornetQ (Artemis) Journal store creates new store files instead of recycling old ones. Whilst bounding write latency this will, over a prolonged interval on sufficiently fast storage media, lead to excessive use of storage space. For our use case it's preferable to have the journal generate write-throttling backpressure from the file recycler. ref https://issues.apache.org/jira/browse/ARTEMIS-2837 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3346) Journal store file count grows unbounded

by Jonathan Halliday (Jira)

Jonathan Halliday created JBTM-3346: --------------------------------------- Summary: Journal store file count grows unbounded Key: JBTM-3346 URL: https://issues.redhat.com/browse/JBTM-3346 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Affects Versions: 5.10.5.Final Reporter: Jonathan Halliday Assignee: Jonathan Halliday Under sustained high load the HornetQ (Artemis) Journal store creates new store files instead of recycling old ones. Whilst bounding write latency this will, over a prolonged interval on sufficiently fast storage media, lead to excessive use of storage space. For our use case it's preferable to have the journal generate write-throttling backpressure from the file recycler. ref https://issues.apache.org/jira/browse/ARTEMIS-2837 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3345) XA_RB* not an error when from end(TMFAIL)

by Anonymous (Jira)

[ https://issues.redhat.com/browse/JBTM-3345?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when jhalliday created pull request #1650 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > XA_RB* not an error when from end(TMFAIL) > ----------------------------------------- > > Key: JBTM-3345 > URL: https://issues.redhat.com/browse/JBTM-3345 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.10.4.Final > Reporter: Jonathan Halliday > Assignee: Jonathan Halliday > Priority: Minor > > When XAResource.end is invoked with TMFAIL i.e. on the rollback path, the RM may use XA_RB* return value to indicate it proactively aborted. This is expected spec compliant behavior and should not result in a WARN log message. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3345) XA_RB* not an error when from end(TMFAIL)

by Jonathan Halliday (Jira)

Jonathan Halliday created JBTM-3345: --------------------------------------- Summary: XA_RB* not an error when from end(TMFAIL) Key: JBTM-3345 URL: https://issues.redhat.com/browse/JBTM-3345 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.10.4.Final Reporter: Jonathan Halliday Assignee: Jonathan Halliday When XAResource.end is invoked with TMFAIL i.e. on the rollback path, the RM may use XA_RB* return value to indicate it proactively aborted. This is expected spec compliant behavior and should not result in a WARN log message. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3297) Move LRA failure records to another part of the store

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3297?page=com.atlassian.jira.plugin... ] Michael Musgrove edited comment on JBTM-3297 at 7/15/20 7:43 AM: ----------------------------------------------------------------- Here is some more detail about what this task entails: After a transaction has prepared we create a transaction record so that if a failure occurs we can recover it. The responsibility for processing failures is the recovery system [1]. We have a number of recovery modules [2], each responsible for a different transaction log type. The different log types are stored in specific locations in the object store (for example LRAs are stored at [7]. The recovery manager periodically asks each recovery module to check for any logs in need of recovery [3]. The recovery module responsible for completing Long Running Actions (LRAs) is [4]. When it runs it looks for records in the store of a specific type/location [5, 7]. But an LRA can finish in a failure state in which case it can never be recovered. However logs in the failed state will be processed on every recovery pass (every few minutes) since they are of the same type as LRA records that do need recovery. This is not efficient (since there will never be a recovery attempt on a failed LRA) and will eventually, if there are many failures, significantly degrade performance. But we still need to keep hold of logs for failed LRAs for reporting purposes so that an external management system can inspect them, for example [6] . This task is to move these failed records to a different location [8] so that the LRA recovery module will ignore them. The LRA recovery coordinator [6] will need to look in this new location when reporting or deleting failed logs. An example of where we already perform this kind of operation is in the ExpiredTransactionScanner#moveEntry [9] [1] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java [2] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryModule.java [3] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java [4] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/internal/LRARecoveryModule.java [5] look for LRARecoveryModule#_transactionType (= io.narayana.lra.coordinator.domain.model.Transaction.getType() ) [6] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/api/RecoveryCoordinator.java (see method getFailedLRAs()) [7] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java (LRA_TYPE = "/StateManager/BasicAction/TwoPhaseCoordinator/LRA") [8] something similar to LRA_FAILED_TYPE = LRA_TYPE + "/Failed" (ie "/StateManager/BascAction/TwoPhaseCoordinator/LRA/Failed") [9] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/ExpiredTransactionScanner.java was (Author: mmusgrov): Here is some more detail about what this task entails: After a transaction has prepared we create a transaction record so that if a failure occurs we can recover it. The responsibility for processing failures is the recovery system [1]. We have a number of recovery modules [2], each responsible for a different transaction log type. The different log types are stored in specific locations in the object store (for example LRAs are stored at [7]. A recovery module manages records of a particular type. The recovery manager periodically asks each recovery module to check for any logs in need of recovery [3]. The recovery module responsible for completing Long Running Actions (LRAs) is [4]. When it runs it looks for records in the store of a specific type/location [5, 7]. But an LRA can finish in a failure state in which case it can never be recovered. However logs in the failed state will be processed on every recovery pass (every few minutes) since they are of the same type as LRA records that do need recovery. This is not efficient (since there will never be a recovery attempt on a failed LRA) and will eventually, if there are many failures, significantly degrade performance. But we still need to keep hold of logs for failed LRAs for reporting purposes so that an external management system can inspect them, for example [6] . This task is to move these failed records to a different location [8] so that the LRA recovery module will ignore them. The LRA recovery coordinator [6] will need to look in this new location when reporting or deleting failed logs. An example of where we already perform this kind of operation is in the ExpiredTransactionScanner#moveEntry [9] [1] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java [2] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryModule.java [3] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java [4] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/internal/LRARecoveryModule.java [5] look for LRARecoveryModule#_transactionType (= io.narayana.lra.coordinator.domain.model.Transaction.getType() ) [6] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/api/RecoveryCoordinator.java (see method getFailedLRAs()) [7] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java (LRA_TYPE = "/StateManager/BasicAction/TwoPhaseCoordinator/LRA") [8] something similar to LRA_FAILED_TYPE = LRA_TYPE + "/Failed" (ie "/StateManager/BascAction/TwoPhaseCoordinator/LRA/Failed") [9] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/ExpiredTransactionScanner.java > Move LRA failure records to another part of the store > ----------------------------------------------------- > > Key: JBTM-3297 > URL: https://issues.redhat.com/browse/JBTM-3297 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Optional > > Prior to JBTM-3247 we deleted LRA failure records (after reporting them). With the fix for JBTM-3247 we now retain failure records which can impact processing of the transaction logs. These records should be moved to another part of the store (note that they can still be queried and deleted by the user). > I have marked the priority as optional even though it is highly desirable. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3297) Move LRA failure records to another part of the store

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3297?page=com.atlassian.jira.plugin... ] Michael Musgrove edited comment on JBTM-3297 at 7/15/20 7:42 AM: ----------------------------------------------------------------- Here is some more detail about what this task entails: After a transaction has prepared we create a transaction record so that if a failure occurs we can recover it. The responsibility for processing failures is the recovery system [1]. We have a number of recovery modules [2], each responsible for a different transaction log type. The different log types are stored in specific locations in the object store (for example LRAs are stored at [7]. A recovery module manages records of a particular type. The recovery manager periodically asks each recovery module to check for any logs in need of recovery [3]. The recovery module responsible for completing Long Running Actions (LRAs) is [4]. When it runs it looks for records in the store of a specific type/location [5, 7]. But an LRA can finish in a failure state in which case it can never be recovered. However logs in the failed state will be processed on every recovery pass (every few minutes) since they are of the same type as LRA records that do need recovery. This is not efficient (since there will never be a recovery attempt on a failed LRA) and will eventually, if there are many failures, significantly degrade performance. But we still need to keep hold of logs for failed LRAs for reporting purposes so that an external management system can inspect them, for example [6] . This task is to move these failed records to a different location [8] so that the LRA recovery module will ignore them. The LRA recovery coordinator [6] will need to look in this new location when reporting or deleting failed logs. An example of where we already perform this kind of operation is in the ExpiredTransactionScanner#moveEntry [9] [1] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java [2] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryModule.java [3] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java [4] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/internal/LRARecoveryModule.java [5] look for LRARecoveryModule#_transactionType (= io.narayana.lra.coordinator.domain.model.Transaction.getType() ) [6] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/api/RecoveryCoordinator.java (see method getFailedLRAs()) [7] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java (LRA_TYPE = "/StateManager/BasicAction/TwoPhaseCoordinator/LRA") [8] something similar to LRA_FAILED_TYPE = LRA_TYPE + "/Failed" (ie "/StateManager/BascAction/TwoPhaseCoordinator/LRA/Failed") [9] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/ExpiredTransactionScanner.java was (Author: mmusgrov): Here is some more detail about what this task entails: After a transaction has prepared we create a transaction record so that if a failure occurs we can recover it. The responsibility for processing failures is the recovery system [1]. We have a number of recovery modules [2], each responsible for a different transaction log type. The different log types are stored in specific locations in the object store (for example LRAs are stored at [7]. A recovery module manages records of a particular type. The recovery manager periodically asks each recovery module to check for any logs in need of recovery [3]. The recovery module responsible for completing Long Running Actions (LRAs) is [4]. When it runs it looks for records in the store of a specific type/location [5, 7]. But an LRA can finish in a failure state in which case it can never be recovered. However logs in the failed state will be processed on every recovery pass (every few minutes) since they are of the same type as LRA records that do need recovery. This is not efficient (since there will never be a recovery attempt on a failed LRA) and will eventually, if there are many failures, significantly degrade performance. But we still need to keep hold of logs for failed LRAs for reporting purposes so that an external management system can inspect them, for example [6] . This task is to move these failed records to a different location [8] so that the LRA recovery module will ignore them. The LRA recovery coordinator [6] will need to look in this new location when reporting or deleting failed logs. An example of where we already perform this kind of operation is in the ExpiredTransactionScanner#moveEntry [9] [1] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java [2] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryModule.java [3] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java [4] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/internal/LRARecoveryModule.java [5] look for LRARecoveryModule#_transactionType (= io.narayana.lra.coordinator.domain.model.Transaction.getType();) [6] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/api/RecoveryCoordinator.java (see method getFailedLRAs()) [7] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java (LRA_TYPE = "/StateManager/BasicAction/TwoPhaseCoordinator/LRA") [8] something similar to LRA_FAILED_TYPE = LRA_TYPE + "/Expired" (ie "/StateManager/BascAction/TwoPhaseCoordinator/LRA/Expired") [9] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/ExpiredTransactionScanner.java > Move LRA failure records to another part of the store > ----------------------------------------------------- > > Key: JBTM-3297 > URL: https://issues.redhat.com/browse/JBTM-3297 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Optional > > Prior to JBTM-3247 we deleted LRA failure records (after reporting them). With the fix for JBTM-3247 we now retain failure records which can impact processing of the transaction logs. These records should be moved to another part of the store (note that they can still be queried and deleted by the user). > I have marked the priority as optional even though it is highly desirable. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3297) Move LRA failure records to another part of the store

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3297?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3297: ---------------------------------------- Here is some more detail about what this task entails: After a transaction has prepared we create a transaction record so that if a failure occurs we can recover it. The responsibility for processing failures is the recovery system [1]. We have a number of recovery modules [2], each responsible for a different transaction log type. The different log types are stored in specific locations in the object store (for example LRAs are stored at [7]. A recovery module manages records of a particular type. The recovery manager periodically asks each recovery module to check for any logs in need of recovery [3]. The recovery module responsible for completing Long Running Actions (LRAs) is [4]. When it runs it looks for records in the store of a specific type/location [5, 7]. But an LRA can finish in a failure state in which case it can never be recovered. However logs in the failed state will be processed on every recovery pass (every few minutes) since they are of the same type as LRA records that do need recovery. This is not efficient (since there will never be a recovery attempt on a failed LRA) and will eventually, if there are many failures, significantly degrade performance. But we still need to keep hold of logs for failed LRAs for reporting purposes so that an external management system can inspect them, for example [6] . This task is to move these failed records to a different location [8] so that the LRA recovery module will ignore them. The LRA recovery coordinator [6] will need to look in this new location when reporting or deleting failed logs. An example of where we already perform this kind of operation is in the ExpiredTransactionScanner#moveEntry [9] [1] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java [2] ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryModule.java [3] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/PeriodicRecovery.java [4] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/internal/LRARecoveryModule.java [5] look for LRARecoveryModule#_transactionType (= io.narayana.lra.coordinator.domain.model.Transaction.getType();) [6] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/api/RecoveryCoordinator.java (see method getFailedLRAs()) [7] rts/lra/lra-coordinator-jar/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java (LRA_TYPE = "/StateManager/BasicAction/TwoPhaseCoordinator/LRA") [8] something similar to LRA_FAILED_TYPE = LRA_TYPE + "/Expired" (ie "/StateManager/BascAction/TwoPhaseCoordinator/LRA/Expired") [9] ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/recovery/ExpiredTransactionScanner.java > Move LRA failure records to another part of the store > ----------------------------------------------------- > > Key: JBTM-3297 > URL: https://issues.redhat.com/browse/JBTM-3297 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Optional > > Prior to JBTM-3247 we deleted LRA failure records (after reporting them). With the fix for JBTM-3247 we now retain failure records which can impact processing of the transaction logs. These records should be moved to another part of the store (note that they can still be queried and deleted by the user). > I have marked the priority as optional even though it is highly desirable. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3297) Move LRA failure records to another part of the store

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3297?page=com.atlassian.jira.plugin... ] Michael Musgrove reassigned JBTM-3297: -------------------------------------- Assignee: Mayank Kunwar (was: Michael Musgrove) > Move LRA failure records to another part of the store > ----------------------------------------------------- > > Key: JBTM-3297 > URL: https://issues.redhat.com/browse/JBTM-3297 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Mayank Kunwar > Priority: Optional > > Prior to JBTM-3247 we deleted LRA failure records (after reporting them). With the fix for JBTM-3247 we now retain failure records which can impact processing of the transaction logs. These records should be moved to another part of the store (note that they can still be queried and deleted by the user). > I have marked the priority as optional even though it is highly desirable. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3308) Some TCK tests pass but leave the LRAs in not finished state

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3308?page=com.atlassian.jira.plugin... ] Martin Stefanko commented on JBTM-3308: --------------------------------------- Resolved as done because with commit [https://github.com/jbosstm/narayana/commit/ff0f7824d668567091473a... are no more open LRAs after the full TCK run. > Some TCK tests pass but leave the LRAs in not finished state > ------------------------------------------------------------ > > Key: JBTM-3308 > URL: https://issues.redhat.com/browse/JBTM-3308 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > It seems that the LRA is correctly closed but the /lra-coordinator still reports it in Active status. -- This message was sent by Atlassian Jira (v7.13.8#713008)

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