May 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1453) Reinstate/review the numbers to detect performance regressions

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1453?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1453: ----------------------------------- Fix Version/s: 5.0.0.M4 (was: 5.0.0.M3) > Reinstate/review the numbers to detect performance regressions > -------------------------------------------------------------- > > Key: JBTM-1453 > URL: https://issues.jboss.org/browse/JBTM-1453 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Performance Testing > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.0.0.M4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1364) Migrate "REST-AT to JTA" bridge into REST-TX component

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1364?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1364: ---------------------------------- Fix Version/s: 5.0.0.M4 (was: 5.0.0.M3) > Migrate "REST-AT to JTA" bridge into REST-TX component > ------------------------------------------------------ > > Key: JBTM-1364 > URL: https://issues.jboss.org/browse/JBTM-1364 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator, REST, TxBridge > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Labels: assign > Fix For: 5.0.0.M4 > > Original Estimate: 1 week > Time Spent: 2 days, 3 hours > Remaining Estimate: 2 days, 5 hours > > The task is to the work Gytis did on his internship and migrate it into the REST-TX project. > Tasks: > 1. Review the current solution looking for: > 1.1 Major issues that prevent an initial release > 1.2 Test coverage > 2. Make any required changes > 3. Merge into the REST-TX project > 4. Migrate the quickstarts accross > 5. Create a blog post > 5.1 Consider what the end user will need to do to use this technology. We may want to wait until REST-AT and this Bridge are shipped with a Narayana build of AS7. Otherwise the steps to get this working could be rather lengthy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1713) Support @Inject of TXDataMap in compensations API prototype

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1713?page=com.atlassian.jira.plugin.... ] Paul Robinson resolved JBTM-1713. --------------------------------- Resolution: Done > Support @Inject of TXDataMap in compensations API prototype > ----------------------------------------------------------- > > Key: JBTM-1713 > URL: https://issues.jboss.org/browse/JBTM-1713 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M3 > > Original Estimate: 4 hours > Time Spent: 4 hours > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1704) Add JavaDoc to Compensations API

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1704?page=com.atlassian.jira.plugin.... ] Paul Robinson resolved JBTM-1704. --------------------------------- Resolution: Done > Add JavaDoc to Compensations API > -------------------------------- > > Key: JBTM-1704 > URL: https://issues.jboss.org/browse/JBTM-1704 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M3 > > Original Estimate: 4 hours > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1713) Support @Inject of TXDataMap in compensations API prototype

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1713?focusedWorklogId=12429215&page=... ] Paul Robinson logged work on JBTM-1713: --------------------------------------- Author: Paul Robinson Created on: 28/May/13 6:28 AM Start Date: 28/May/13 6:28 AM Worklog Time Spent: 4 hours Issue Time Tracking ------------------- Remaining Estimate: 0 minutes (was: 4 hours) Time Spent: 4 hours Worklog Id: (was: 12429215) > Support @Inject of TXDataMap in compensations API prototype > ----------------------------------------------------------- > > Key: JBTM-1713 > URL: https://issues.jboss.org/browse/JBTM-1713 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M3 > > Original Estimate: 4 hours > Time Spent: 4 hours > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1717) Compensations API tests hit by ParticipantCompletion Race condition

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1717?page=com.atlassian.jira.plugin.... ] Paul Robinson resolved JBTM-1717. --------------------------------- Resolution: Done > Compensations API tests hit by ParticipantCompletion Race condition > ------------------------------------------------------------------- > > Key: JBTM-1717 > URL: https://issues.jboss.org/browse/JBTM-1717 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.0.M3 > > > This issue is documented here: JBTM-1429 > This issue is to fix the tests so they tollerate this issue. This can be solved easily using Byteman, in the same way as we solve it for other tests. > In the documentation for JBTM-1429, we state that this issue is unlikely to happen in a distributed environment. This is true, however, the Compensations API is designed to work local-only as well as distributed over WS-BA. See JBTM-1718 for the real fix to this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1694) Use emma jar from a Maven repo instead of checking into the build

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1694?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1694: -------------------------------- Fix Version/s: 5.0.0.M4 (was: 5.0.0.M3) > Use emma jar from a Maven repo instead of checking into the build > ----------------------------------------------------------------- > > Key: JBTM-1694 > URL: https://issues.jboss.org/browse/JBTM-1694 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Weinan Li > Assignee: Tom Jenkinson > Fix For: 4.17.5, 5.0.0.M4 > > > Currently in /pom.xml: > {code} > <systemPath>${emma.jar.location}</systemPath> > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka commented on JBTM-1147: ---------------------------------------- I did a first attempt on solving this issue: https://github.com/ochaloup/narayana/commits/JBTM-1147-xts-crash-byteman-... We agreed with Paul that he needs to revisit the goals of the issue because of this the issue was moved to next release. > Refactor ParticipantCompletion recovery tests to remove duplicate rules > ----------------------------------------------------------------------- > > Key: JBTM-1147 > URL: https://issues.jboss.org/browse/JBTM-1147 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: XTS > Affects Versions: 4.16.4, 5.0.0.M1 > Reporter: Paul Robinson > Assignee: Ondřej Chaloupka > Priority: Minor > Fix For: 5.0.0.M4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example: > The following rules in BACrashDuringCommit could be refactored into a single rule > {code} > ##################################################################### > # Setup counter MultiParticipantParticipantCompletionParticipantCloseTest > # > RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest > METHOD run() > AT ENTRY > IF TRUE > DO debug("creating counter and rendezvous"), > createCounter("closes", 3), > createRendezvous("closes-complete", 2) > ENDRULE > ##################################################################### > # Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest > # > RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest > METHOD run() > AT ENTRY > IF TRUE > DO debug("creating counter and rendezvous"), > createCounter("closes", 3), > createRendezvous("closes-complete", 2) > ENDRULE > ##################################################################### > # Setup counter MultiServiceParticipantCompletionParticipantCloseTest > # > RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest > METHOD run() > AT ENTRY > IF TRUE > DO debug("creating counter and rendezvous"), > createCounter("closes", 3), > createRendezvous("closes-complete", 2) > ENDRULE > ##################################################################### > # Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest > # > RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest > METHOD run() > AT ENTRY > IF TRUE > DO debug("creating counter and rendezvous"), > createCounter("closes", 3), > createRendezvous("closes-complete", 2) > ENDRULE > {code} > These can be re-factored in to a rule like this: > {code} > RULE setup counter > INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest > METHOD run() > AT ENTRY > IF $0.getClass().getName().contains("ParticipantCompletionParticipant") > DO debug("creating counter and rendezvous"), > createCounter("closes", 3), > createRendezvous("closes-complete", 2) > ENDRULE > {code} > This assumes that we have the same numbers for each use of: > {code} > createCounter("closes", 3), > createRendezvous("closes-complete", 2) > {code} > Which is *usually* the case: > {code} > grep -r createCounter\(\"closes\" . > ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1), > ./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3), > ./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3), > ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3), > ./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1), > ./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3), > ./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3), > {code} > Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated. > Also, the following similar rules are also present in this file: > {code} > ##################################################################### > # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest > # > RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest > METHOD run() > AT CALL UserBusinessActivity.close() > IF TRUE > DO debug("waiting to call close"), > rendezvous("closes-complete"), > debug("rendezvous complete, calling close") > ENDRULE > ##################################################################### > # Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest > # > RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest > METHOD run() > AT CALL UserBusinessActivity.close() > IF TRUE > DO debug("waiting to call close"), > rendezvous("closes-complete"), > debug("rendezvous complete, calling close") > ENDRULE > ##################################################################### > # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest > # > RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest > METHOD run() > AT CALL UserBusinessActivity.close() > IF TRUE > DO debug("waiting to call close"), > rendezvous("closes-complete"), > debug("rendezvous complete, calling close") > ENDRULE > ##################################################################### > # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest > # > RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest > CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest > METHOD run() > AT CALL UserBusinessActivity.close() > IF TRUE > DO debug("waiting to call close"), > rendezvous("closes-complete"), > debug("rendezvous complete, calling close") > ENDRULE > {code} > Which could be replaced with something like this: > {code} > RULE wait for closes > INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest > METHOD run() > AT CALL UserBusinessActivity.close() > IF $0.getClass().getName().contains("ParticipantCompletionParticipant") > DO debug("waiting to call close"), > rendezvous("closes-complete"), > debug("rendezvous complete, calling close") > ENDRULE > {code} > We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1171) improve XAResource preparefailed logging

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1171?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1171: ----------------------------------- Fix Version/s: 4.17.5 > improve XAResource preparefailed logging > ---------------------------------------- > > Key: JBTM-1171 > URL: https://issues.jboss.org/browse/JBTM-1171 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 4.6.1.CP12 > Reporter: Jonathan Halliday > Assignee: Michael Musgrove > Fix For: 4.6.1.CP13, 4.17.5 > > > com.arjuna.ats.internal.jta.resources.arjunacore.preparefailed does not log the underlying XA exception. In cases where e.g. db constraints are deferred to tx commit time, such errors can contain useful information. > Note that non-deferred constraints are covered by JBTM-575 as the problem manifests at the earlier beforeCompletion (i.e. sql flush) stage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1171) improve XAResource preparefailed logging

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1171?page=com.atlassian.jira.plugin.... ] Michael Musgrove reassigned JBTM-1171: -------------------------------------- Assignee: Michael Musgrove (was: Jonathan Halliday) > improve XAResource preparefailed logging > ---------------------------------------- > > Key: JBTM-1171 > URL: https://issues.jboss.org/browse/JBTM-1171 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 4.6.1.CP12 > Reporter: Jonathan Halliday > Assignee: Michael Musgrove > Fix For: 4.6.1.CP13 > > > com.arjuna.ats.internal.jta.resources.arjunacore.preparefailed does not log the underlying XA exception. In cases where e.g. db constraints are deferred to tx commit time, such errors can contain useful information. > Note that non-deferred constraints are covered by JBTM-575 as the problem manifests at the earlier beforeCompletion (i.e. sql flush) stage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 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 May 2013