August 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1431) LastResourceRecord.shouldAdd allows insertion regardless of order and type info

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1431?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-1431: --------------------------------- > LastResourceRecord.shouldAdd allows insertion regardless of order and type info > ------------------------------------------------------------------------------- > > Key: JBTM-1431 > URL: https://issues.jboss.org/browse/JBTM-1431 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 4.17.3 > Reporter: Mark Little > Assignee: Mark Little > > So looking at the code, LastResource is meant to be ordered last in the intentions list (check topLevelPrepare to see this). However, a quick look at the code in LastResourceRecord shows that there is a bug: > public boolean shouldAdd (AbstractRecord a) > { > if (a.typeIs() == typeIs()) > { > if (ALLOW_MULTIPLE_LAST_RESOURCES) { > if (!_disableMLRWarning > || (_disableMLRWarning && !_issuedWarning)) { > tsLogger.i18NLogger.warn_lastResource_multipleWarning(a.toString()); > _issuedWarning = true; > } > return true; > } > else { > tsLogger.i18NLogger.warn_lastResource_disallow(this.toString(), a.toString()); > return false; > } > } > else > { > return true; <------- Here is the bug! > } > } > Basically if the record to be added is not a LastResourceRecord then it gets added immediately, ignoring any further checks on type, order etc. This is wrong. > And looking back at the code from 6 years ago we see that this was much simpler: > public boolean shouldAdd (AbstractRecord a) > { > return (a.typeIs() == typeIs()) ; > } -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1431) LastResourceRecord.shouldAdd allows insertion regardless of order and type info

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1431?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1431: -------------------------------- Fix Version/s: 4.17.9 5.0.0.M2 > LastResourceRecord.shouldAdd allows insertion regardless of order and type info > ------------------------------------------------------------------------------- > > Key: JBTM-1431 > URL: https://issues.jboss.org/browse/JBTM-1431 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 4.17.3 > Reporter: Mark Little > Assignee: Mark Little > Fix For: 4.17.9, 5.0.0.M2 > > > So looking at the code, LastResource is meant to be ordered last in the intentions list (check topLevelPrepare to see this). However, a quick look at the code in LastResourceRecord shows that there is a bug: > public boolean shouldAdd (AbstractRecord a) > { > if (a.typeIs() == typeIs()) > { > if (ALLOW_MULTIPLE_LAST_RESOURCES) { > if (!_disableMLRWarning > || (_disableMLRWarning && !_issuedWarning)) { > tsLogger.i18NLogger.warn_lastResource_multipleWarning(a.toString()); > _issuedWarning = true; > } > return true; > } > else { > tsLogger.i18NLogger.warn_lastResource_disallow(this.toString(), a.toString()); > return false; > } > } > else > { > return true; <------- Here is the bug! > } > } > Basically if the record to be added is not a LastResourceRecord then it gets added immediately, ignoring any further checks on type, order etc. This is wrong. > And looking back at the code from 6 years ago we see that this was much simpler: > public boolean shouldAdd (AbstractRecord a) > { > return (a.typeIs() == typeIs()) ; > } -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1431) LastResourceRecord.shouldAdd allows insertion regardless of order and type info

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1431?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1431. --------------------------------- Resolution: Done > LastResourceRecord.shouldAdd allows insertion regardless of order and type info > ------------------------------------------------------------------------------- > > Key: JBTM-1431 > URL: https://issues.jboss.org/browse/JBTM-1431 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 4.17.3 > Reporter: Mark Little > Assignee: Mark Little > Fix For: 4.17.9, 5.0.0.M2 > > > So looking at the code, LastResource is meant to be ordered last in the intentions list (check topLevelPrepare to see this). However, a quick look at the code in LastResourceRecord shows that there is a bug: > public boolean shouldAdd (AbstractRecord a) > { > if (a.typeIs() == typeIs()) > { > if (ALLOW_MULTIPLE_LAST_RESOURCES) { > if (!_disableMLRWarning > || (_disableMLRWarning && !_issuedWarning)) { > tsLogger.i18NLogger.warn_lastResource_multipleWarning(a.toString()); > _issuedWarning = true; > } > return true; > } > else { > tsLogger.i18NLogger.warn_lastResource_disallow(this.toString(), a.toString()); > return false; > } > } > else > { > return true; <------- Here is the bug! > } > } > Basically if the record to be added is not a LastResourceRecord then it gets added immediately, ignoring any further checks on type, order etc. This is wrong. > And looking back at the code from 6 years ago we see that this was much simpler: > public boolean shouldAdd (AbstractRecord a) > { > return (a.typeIs() == typeIs()) ; > } -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1645) Allow pull requests to configure some parameters in scripts/hudson/narayana.sh

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1645?page=com.atlassian.jira.plugin.... ] Work on JBTM-1645 started by Gytis Trikleris. > Allow pull requests to configure some parameters in scripts/hudson/narayana.sh > ------------------------------------------------------------------------------ > > Key: JBTM-1645 > URL: https://issues.jboss.org/browse/JBTM-1645 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.0.M5 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > If the pull description has something like this: > export NARAYANA_BUILD=1 AS_BUILD=1 NARAYANA_TESTS=1 TXF_TESTS=1 XTS_TESTS=1 XTS_AS_TESTS=1 txbridge=1 QA_TESTS=1 [SUN_ORB=0] [JAC_ORB=1] [QA_TARGET=ci-jts-tests] > We could use it in scripts/hudson/narayana.sh if we detect it is a pull build. We might need to white list users we apply this to. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1464) Some performance tests are missing the timing code.

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1464?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1464: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Some performance tests are missing the timing code. > --------------------------------------------------- > > Key: JBTM-1464 > URL: https://issues.jboss.org/browse/JBTM-1464 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Performance Testing, Testing, Transaction Core > Affects Versions: 4.17.3 > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Trivial > Fix For: 5.0.0.Final > > > The TXOJ performance tests are supposed to get the start time before running and then the end time after completion, printing out the difference. It seems that in several of them, the end time is no longer obtained and nothing is printed out either, i.e., no elapsed time is given. This makes these tests pretty useless as performance tests. Rather than remove the tests, the elapsed time check should be put back. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1431) LastResourceRecord.shouldAdd allows insertion regardless of order and type info

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1431?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1431: ----------------------------------------------- James Livingston <jlivings(a)redhat.com> made a comment on [bug 1001909|https://bugzilla.redhat.com/show_bug.cgi?id=1001909] Due to https://issues.jboss.org/browse/JBTM-1431, it is possible for a last resource (e.g. non-XA resource) to be committed prior to another XA resource, which is unsafe. This was fixed in master prior to 6.1, but not in a bugfix release so was not pulled into EAP. > LastResourceRecord.shouldAdd allows insertion regardless of order and type info > ------------------------------------------------------------------------------- > > Key: JBTM-1431 > URL: https://issues.jboss.org/browse/JBTM-1431 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 4.17.3 > Reporter: Mark Little > Assignee: Mark Little > > So looking at the code, LastResource is meant to be ordered last in the intentions list (check topLevelPrepare to see this). However, a quick look at the code in LastResourceRecord shows that there is a bug: > public boolean shouldAdd (AbstractRecord a) > { > if (a.typeIs() == typeIs()) > { > if (ALLOW_MULTIPLE_LAST_RESOURCES) { > if (!_disableMLRWarning > || (_disableMLRWarning && !_issuedWarning)) { > tsLogger.i18NLogger.warn_lastResource_multipleWarning(a.toString()); > _issuedWarning = true; > } > return true; > } > else { > tsLogger.i18NLogger.warn_lastResource_disallow(this.toString(), a.toString()); > return false; > } > } > else > { > return true; <------- Here is the bug! > } > } > Basically if the record to be added is not a LastResourceRecord then it gets added immediately, ignoring any further checks on type, order etc. This is wrong. > And looking back at the code from 6 years ago we see that this was much simpler: > public boolean shouldAdd (AbstractRecord a) > { > return (a.typeIs() == typeIs()) ; > } -- 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, 8 months

1
0
0 / 0

[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 commented on JBTM-1453: ---------------------------------------- I have create the job narayana-QA-PerformanceTesting to test for regressions on haverstraw > 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.Final > > 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1464) Some performance tests are missing the timing code.

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1464?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1464: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/413 > Some performance tests are missing the timing code. > --------------------------------------------------- > > Key: JBTM-1464 > URL: https://issues.jboss.org/browse/JBTM-1464 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Performance Testing, Testing, Transaction Core > Affects Versions: 4.17.3 > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Trivial > Fix For: 5.0.0.Final > > > The TXOJ performance tests are supposed to get the start time before running and then the end time after completion, printing out the difference. It seems that in several of them, the end time is no longer obtained and nothing is printed out either, i.e., no elapsed time is given. This makes these tests pretty useless as performance tests. Rather than remove the tests, the elapsed time check should be put back. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-987) Document Compensations API

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-987?page=com.atlassian.jira.plugin.s... ] Paul Robinson updated JBTM-987: ------------------------------- Fix Version/s: 5.0.0.M5 (was: 5.0.0.Final) > Document Compensations API > -------------------------- > > Key: JBTM-987 > URL: https://issues.jboss.org/browse/JBTM-987 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: TXFramework > Reporter: Paul Robinson > Priority: Optional > Labels: Documentation,, TXFramework > Fix For: 5.0.0.M5 > > > Should cover all existing features and provide a skeleton for the final document. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1390) Update BaseCrashTest to use global arguments

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1390?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1390: -------------------------------- Fix Version/s: 5.0.0.M5 (was: 5.0.0.Final) > Update BaseCrashTest to use global arguments > -------------------------------------------- > > Key: JBTM-1390 > URL: https://issues.jboss.org/browse/JBTM-1390 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Testing, XTS > Reporter: Paul Robinson > Priority: Minor > Fix For: 5.0.0.M5 > > > Ideally we should only have the byteman, memory and ipv6 args in a single place (root pom.xml). However, these are hardcoded in the BaseCrashTest of the XTS recovery tests. > These should be using the values set in the pom. > {code} > protected String BytemanArgs = "-Xms64m -Xmx1024m -XX:MaxPermSize=512m -Dorg.jboss.byteman.verbose -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.byteman.transform.all -javaagent:target/test-classes/lib/byteman.jar=script:target/test-classes/scripts/@BMScript@.txt,boot:target/test-classes/lib/byteman.jar,listener:true"; > protected String iPv6Args = "-Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true -Djboss.bind.address=[::1] -Djboss.bind.address.management=[::1] -Djboss.bind.address.unsecure=[::1] "; > {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, 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 2013