[JBoss JIRA] (JBTM-2583) Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2583:
--------------------------------
Fix Version/s: 5.later
(was: 6.later)
> Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2583
> URL: https://issues.jboss.org/browse/JBTM-2583
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.later
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>
> * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (JBTM-2583) Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2583:
--------------------------------
Issue Type: Enhancement (was: Feature Request)
> Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2583
> URL: https://issues.jboss.org/browse/JBTM-2583
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.later
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>
> * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (JBTM-2583) Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2583:
--------------------------------
Description:
Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
* In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
* In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed
was:
Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
There are a couple of advantages to this:
1. In the common case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
2. In the case where the recovery manager and transaction manager are distributed, the current behaviour of orphan detection can be employed (or the timeout interval extended)
> Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2583
> URL: https://issues.jboss.org/browse/JBTM-2583
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 6.later
>
>
> Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager.
> This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back.
>
> * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely
> * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2409:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> XARecoveryModuleHelpersUnitTest hang
> ------------------------------------
>
> Key: JBTM-2409
> URL: https://issues.jboss.org/browse/JBTM-2409
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Recovery
> Affects Versions: 5.1.1
> Reporter: Michael Musgrove
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.next
>
> Attachments: 32287.jstack, hang.jstack
>
>
> The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang.
> The junit test thread:
> - starts 2 threads that will remove a recovery helper
> - triggers xaRecoveryModule.periodicWorkFirstPass()
> - triggers xaRecoveryModule.periodicWorkSecondPass()
> - joins with remover threads
> The jstack output shows:
> - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish;
> - the junit test thread is waiting to join with these two threads;
> Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Gytis Trikleris created pull request #979 in GitHub
---------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> Think of the possibility to improve Compensations API with lambdas
> ------------------------------------------------------------------
>
> Key: JBTM-2458
> URL: https://issues.jboss.org/browse/JBTM-2458
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: TXFramework
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.next
>
>
> Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation.
> We should try to think of the best API changes to introduce that.
> We could rewrite MongoDB quickstart to make it easier to visualise the difference.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.... ]
Michael Musgrove edited comment on JBTM-2624 at 2/18/16 5:47 AM:
-----------------------------------------------------------------
[~tomjenkinson] [~zhfeng] The CLI is documented in the [tools section|http://narayana.io/docs/product/index.html#d0e2725] of our product manual.
was (Author: mmusgrov):
[~tomjenkinson] [~zhfeng] The CLI is documented in the [tools|http://narayana.io/docs/product/index.html#d0e2725] of our product manual.
> Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2624
> URL: https://issues.jboss.org/browse/JBTM-2624
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
>
> {quote}
> We have several management ways in Karaf :
> * mbeans (no need to rewrap them)
> * shell commands
> * a servlet for the felix web console (used by the community)
> * a hawtio plugin (used by fuse)
> The first two are the most important imho.
> {quote}
> the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2624:
----------------------------------------
[~tomjenkinson] [~zhfeng] The CLI is documented in the [tools|http://narayana.io/docs/product/index.html#d0e2725] of our product manual.
> Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf
> -----------------------------------------------------------------------------------
>
> Key: JBTM-2624
> URL: https://issues.jboss.org/browse/JBTM-2624
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
>
> {quote}
> We have several management ways in Karaf :
> * mbeans (no need to rewrap them)
> * shell commands
> * a servlet for the felix web console (used by the community)
> * a hawtio plugin (used by fuse)
> The first two are the most important imho.
> {quote}
> the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months