August 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1922) RTS error and warning messages do have unique codes for identification purposes

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1922?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1922: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > RTS error and warning messages do have unique codes for identification purposes > ------------------------------------------------------------------------------- > > Key: JBTM-1922 > URL: https://issues.jboss.org/browse/JBTM-1922 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Affects Versions: 5.0.0.M4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Original Estimate: 2 days > Remaining Estimate: 2 days > > ANDIAMO-7 says that all error and warning messages should have a unique code that can be used to identify them. RTS does not conform with this requirement. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1853) RESTAT does not expose recovery URIs after a crash

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1853?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1853: ----------------------------------- Fix Version/s: 5.later > RESTAT does not expose recovery URIs after a crash > -------------------------------------------------- > > Key: JBTM-1853 > URL: https://issues.jboss.org/browse/JBTM-1853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > The RESTAT coordinator creates a participant-recovery URI during participant enlistment. This URI should exist for as long as the participant participates in the transaction including during recovery time. After a coordinator crash GET requests return 404 instead of returning the participant resource URI -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1853) RESTAT does not expose recovery URIs after a crash

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1853?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1853: ----------------------------------- Fix Version/s: (was: 5.next) > RESTAT does not expose recovery URIs after a crash > -------------------------------------------------- > > Key: JBTM-1853 > URL: https://issues.jboss.org/browse/JBTM-1853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > The RESTAT coordinator creates a participant-recovery URI during participant enlistment. This URI should exist for as long as the participant participates in the transaction including during recovery time. After a coordinator crash GET requests return 404 instead of returning the participant resource URI -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2419) Consider reducing the number of JMH perf test forks on PRs

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2419?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2419: ----------------------------------- Fix Version/s: (was: 5.next) > Consider reducing the number of JMH perf test forks on PRs > ---------------------------------------------------------- > > Key: JBTM-2419 > URL: https://issues.jboss.org/browse/JBTM-2419 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > We run our JMH tests multiple times in order to estimate run-to-run variance. The [JMH docs|http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/m...] state: > bq. JVMs are complex systems, and the non-determinism is inherent for them. This requires us to always account the run-to-run variance as the one of the effects in our experiments. Forking aggregates the results across several JVM launches. > Currently we set the number of forks to 10. We run each test 6 times with each run lasting 1 min. Since we have 10 tests this means it takes 10 * 10 * 6 minutes for the benchmarks to complete. In the future we want to keep adding new performance tests and the time taken to run a PR will become prohibitive. I would like to propose one of the following solutions: > - reduce the number of forks; > - run a subset of performance tests on each PR and then run them all once a week or so on the main build > My preference is to reduce the number of forks to 3. Note that the PR requester has the option to disable performance tests for his PR (by including !PERF in the comment section). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2483) Investigate ways to test Docker quickstarts

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2483?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-2483: ---------------------------------- Fix Version/s: 5.later (was: 5.next) > Investigate ways to test Docker quickstarts > ------------------------------------------- > > Key: JBTM-2483 > URL: https://issues.jboss.org/browse/JBTM-2483 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.later > > > Currently there is only one quickstart for docker (at the moment in the PR queue), but its tests are disabled by default. However, it would be good to run them in our CI. > We'll have the same problem in the future with Kubernetes quickstarts. > Maybe Arquillian Cube is something what could help? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1856) Provide a transactional driver quickstart

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1856?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1856: -------------------------------- Fix Version/s: 5.later (was: 5.next) > Provide a transactional driver quickstart > ----------------------------------------- > > Key: JBTM-1856 > URL: https://issues.jboss.org/browse/JBTM-1856 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.later > > > Provide a simple example of a standalone application using Narayana with Transactional Driver. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2329) Add a management API that an AbstractRecord provider can implement to clear the heuristic state of a transaction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2329?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2329: -------------------------------- Reporter: Michael Musgrove (was: Tom Jenkinson) > Add a management API that an AbstractRecord provider can implement to clear the heuristic state of a transaction > ---------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2329 > URL: https://issues.jboss.org/browse/JBTM-2329 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > If an AbstractRecord type has resulted in a heuristic state, it would be useful to provide some form of management API to clear the state on the resource manager. > After discussion on the forum, it seems likely the API would be something like: > Update AbstractRecord to change the return type of value() to the HeuristicManagement interface (rather than Object). Although value() is maybe not the most accurate term and it does appear that this is used internally by XAResourceRecord in an unintended manner (i.e. not dealing with HeuristicInformation. > Add a new interface of modify the existing HeuristicInformation (the current version of which is to be deprecated in: JBTM-2328) > {code} > public interface HeuristicManagement > { > public void resolve() throws CouldNotResolveException; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2329) Add a management API that an AbstractRecord provider can implement to clear the heuristic state of a transaction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2329?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2329: -------------------------------- Fix Version/s: 5.later > Add a management API that an AbstractRecord provider can implement to clear the heuristic state of a transaction > ---------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2329 > URL: https://issues.jboss.org/browse/JBTM-2329 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.later > > > If an AbstractRecord type has resulted in a heuristic state, it would be useful to provide some form of management API to clear the state on the resource manager. > After discussion on the forum, it seems likely the API would be something like: > Update AbstractRecord to change the return type of value() to the HeuristicManagement interface (rather than Object). Although value() is maybe not the most accurate term and it does appear that this is used internally by XAResourceRecord in an unintended manner (i.e. not dealing with HeuristicInformation. > Add a new interface of modify the existing HeuristicInformation (the current version of which is to be deprecated in: JBTM-2328) > {code} > public interface HeuristicManagement > { > public void resolve() throws CouldNotResolveException; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2326) Provide a management interface to see a list of Xids that are being being considered for recovery by the recovery manager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2326?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2326: -------------------------------- Fix Version/s: 5.later > Provide a management interface to see a list of Xids that are being being considered for recovery by the recovery manager > ------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2326 > URL: https://issues.jboss.org/browse/JBTM-2326 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA, Tooling > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.later > > > Although it is possible to see the list of current transactions in the CLI, for those branches that are available for recovery it can be useful to see the list that the recovery manager is considering. I have often looked in the debugger at this state: > https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com... so it might be useful to others. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1952) Implement XTSATRecoveryManager and XTSBARecoveryManager injection

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1952?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1952: -------------------------------- Fix Version/s: (was: 6.later) > Implement XTSATRecoveryManager and XTSBARecoveryManager injection > ----------------------------------------------------------------- > > Key: JBTM-1952 > URL: https://issues.jboss.org/browse/JBTM-1952 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > Change polling introduced with JBTM-1917 with proper CDI injection. > See JBTM-1639 for the detailed background on the issue before JBTM-1917 workaround. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 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 2015