July 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1813) org.jboss.jbossts.jts:jbossjts-jacorb:jar:4.17.5.Final-SNAPSHOT artefact is missing

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1813?page=com.atlassian.jira.plugin.... ] Michael Musgrove resolved JBTM-1813. ------------------------------------ Fix Version/s: 5.0.0.M4 Resolution: Done I updated the version with commit 7b28d7e655a21f12 Instead of tweaking the wiki instructions I added pre-release-vars.sh to the list of files to be updated to the next revision. I did this on the 4.17 branch and master. > org.jboss.jbossts.jts:jbossjts-jacorb:jar:4.17.5.Final-SNAPSHOT artefact is missing > ----------------------------------------------------------------------------------- > > Key: JBTM-1813 > URL: https://issues.jboss.org/browse/JBTM-1813 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 4.16.7, 5.0.0.M4 > > > http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61/1802 > http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61/1803 > {code} > Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/jbossts... > Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/jbossts... > [WARNING] The POM for org.jboss.jbossts.jts:jbossjts-jacorb:jar:4.17.5.Final-SNAPSHOT is missing, no dependency information available > Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/jbossts... > {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-1819) rest_at_integration_tests not ran due to typo

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1819?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1819: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/366 > rest_at_integration_tests not ran due to typo > --------------------------------------------- > > Key: JBTM-1819 > URL: https://issues.jboss.org/browse/JBTM-1819 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.0.0.M4 > > > There is a typo in narayana.sh, a function called rest_at_integration_tests exists but the script tries to call rest_at_integration_test. > I have commented on the original commit over here: > https://github.com/jbosstm/narayana/commit/34930058e2a3387a0139cd9a45e94c... -- 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-1819) rest_at_integration_tests not ran due to typo

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-1819: ----------------------------------- Summary: rest_at_integration_tests not ran due to typo Key: JBTM-1819 URL: https://issues.jboss.org/browse/JBTM-1819 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Build System Reporter: Tom Jenkinson Assignee: Gytis Trikleris Fix For: 5.0.0.M4 There is a typo in narayana.sh, a function called rest_at_integration_tests exists but the script tries to call rest_at_integration_test. I have commented on the original commit over here: https://github.com/jbosstm/narayana/commit/34930058e2a3387a0139cd9a45e94c... -- 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-1495) Merge in BlackTie

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1495?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1495: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Leaving forums separate for now > Merge in BlackTie > ----------------- > > Key: JBTM-1495 > URL: https://issues.jboss.org/browse/JBTM-1495 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.M4 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Docs, code, forums, chat room (motd), Jira, web pages > Need to add *.c, *.bat, *.sh, makefile to NarayanaReleaseProcess script when search and replacing -- 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-1808) Investigate why QA tests take 5hrs to run per ORB

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1808?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1808: -------------------------------- Priority: Minor (was: Major) > Investigate why QA tests take 5hrs to run per ORB > ------------------------------------------------- > > Key: JBTM-1808 > URL: https://issues.jboss.org/browse/JBTM-1808 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System, Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.0.0.Final > > > Our full build and test suite takes 12hrs to run. This is causing severe strain on our CI resources. > Out of this 12hrs, 10hrs is consumed by the QA test suite (5hrs per orb). It would be good to understand where this time is spent so that we can hopefully bring the test time down. > If there is no reasonable way to bring the timing down, we could chop the tests up into 5 groups (per orb) taking 1hr each. This would make better use of our CI cluster during quiet periods, but will not eleviate the load during busy periods. It is also likely to be a poor usage of resources as I suspect the CPU utilisation of each job will be low. > I suspect the problem is that we have a lot of Thread.sleeps in the tests. Therefore we are likely to see long tests with low resource (CPU) utilisation. However, further investigation is required to understand where the time is spent. > As an initial investigation, it would be good to profile the CPU utilisation on one of the CI nodes (take it offline) whilst running these tests. Also, it would be handy to find out how much time is spent in a Thread.sleep call (assuming that is where the time is spent). > My understanding is that Thread.sleep is used to wait for certain background tasks to complete. It's likely that Byteman could be used to replace the sleeps. However, due to the number of tests this may not be feasible. Alternatively, we may discover that there is a common set of Byteman rules that could be applied to the majority of tests, which may prove "good enough". > Also, we may be able to run these tests in parallel. This could drive up CPU utilisation, but would probably also interfere with the timings of the tests meaning that the current thread.sleeps are no longer adequate. > To summarise, this is a general task to investigate why the tests take so long and to also come up with some candidate solutions to bring the total test duration down. -- 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-1763) Consider running the QA tests in parrallel

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1763?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1763: -------------------------------- Fix Version/s: 5.0.0.Final (was: 5.0.0.M4) > Consider running the QA tests in parrallel > ------------------------------------------ > > Key: JBTM-1763 > URL: https://issues.jboss.org/browse/JBTM-1763 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.0.0.Final > > > The QA tests currently take 5hrs to run per orb. This constitutes 83% of our CI run time. > My understanding is that the time is mostly taken up in Thread.sleep. The test times range from 1 to 99seconds. So there are no major hotspots. The problem is that there are so many tests. > I suspect we could run these tests in parallel to make better utilisation of resources. > The tests don't run in an AS, but they do acquire ports. There may be other restrictions that make running them in parallel hard or impossible. > It would be easier to simply carve up the tests into, say 5 parts per orb and have CI do the parallelism. However, this will consume more CI nodes than if we ran them in parallel on a single node. > I think it would be worth investigating if we can run the tests in n batches (say n=10 initially, but should be configurable). Where each batch runs with a different port configuration. This may prove too disruptive to the tests, > and also more bother than it is worth. Maybe we could do an initial investigation to see if this has legs? -- 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-1808) Investigate why QA tests take 5hrs to run per ORB

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1808?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1808: -------------------------------- Assignee: Amos Feng (was: Tom Jenkinson) > Investigate why QA tests take 5hrs to run per ORB > ------------------------------------------------- > > Key: JBTM-1808 > URL: https://issues.jboss.org/browse/JBTM-1808 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System, Testing > Reporter: Paul Robinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.0.0.Final > > > Our full build and test suite takes 12hrs to run. This is causing severe strain on our CI resources. > Out of this 12hrs, 10hrs is consumed by the QA test suite (5hrs per orb). It would be good to understand where this time is spent so that we can hopefully bring the test time down. > If there is no reasonable way to bring the timing down, we could chop the tests up into 5 groups (per orb) taking 1hr each. This would make better use of our CI cluster during quiet periods, but will not eleviate the load during busy periods. It is also likely to be a poor usage of resources as I suspect the CPU utilisation of each job will be low. > I suspect the problem is that we have a lot of Thread.sleeps in the tests. Therefore we are likely to see long tests with low resource (CPU) utilisation. However, further investigation is required to understand where the time is spent. > As an initial investigation, it would be good to profile the CPU utilisation on one of the CI nodes (take it offline) whilst running these tests. Also, it would be handy to find out how much time is spent in a Thread.sleep call (assuming that is where the time is spent). > My understanding is that Thread.sleep is used to wait for certain background tasks to complete. It's likely that Byteman could be used to replace the sleeps. However, due to the number of tests this may not be feasible. Alternatively, we may discover that there is a common set of Byteman rules that could be applied to the majority of tests, which may prove "good enough". > Also, we may be able to run these tests in parallel. This could drive up CPU utilisation, but would probably also interfere with the timings of the tests meaning that the current thread.sleeps are no longer adequate. > To summarise, this is a general task to investigate why the tests take so long and to also come up with some candidate solutions to bring the total test duration down. -- 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-1808) Investigate why QA tests take 5hrs to run per ORB

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1808?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1808: -------------------------------- Fix Version/s: 5.0.0.Final (was: 5.0.0.M4) > Investigate why QA tests take 5hrs to run per ORB > ------------------------------------------------- > > Key: JBTM-1808 > URL: https://issues.jboss.org/browse/JBTM-1808 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System, Testing > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.Final > > > Our full build and test suite takes 12hrs to run. This is causing severe strain on our CI resources. > Out of this 12hrs, 10hrs is consumed by the QA test suite (5hrs per orb). It would be good to understand where this time is spent so that we can hopefully bring the test time down. > If there is no reasonable way to bring the timing down, we could chop the tests up into 5 groups (per orb) taking 1hr each. This would make better use of our CI cluster during quiet periods, but will not eleviate the load during busy periods. It is also likely to be a poor usage of resources as I suspect the CPU utilisation of each job will be low. > I suspect the problem is that we have a lot of Thread.sleeps in the tests. Therefore we are likely to see long tests with low resource (CPU) utilisation. However, further investigation is required to understand where the time is spent. > As an initial investigation, it would be good to profile the CPU utilisation on one of the CI nodes (take it offline) whilst running these tests. Also, it would be handy to find out how much time is spent in a Thread.sleep call (assuming that is where the time is spent). > My understanding is that Thread.sleep is used to wait for certain background tasks to complete. It's likely that Byteman could be used to replace the sleeps. However, due to the number of tests this may not be feasible. Alternatively, we may discover that there is a common set of Byteman rules that could be applied to the majority of tests, which may prove "good enough". > Also, we may be able to run these tests in parallel. This could drive up CPU utilisation, but would probably also interfere with the timings of the tests meaning that the current thread.sleeps are no longer adequate. > To summarise, this is a general task to investigate why the tests take so long and to also come up with some candidate solutions to bring the total test duration down. -- 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-1523) Try to have XTS enabled in standalone-full.xml

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1523?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1523: -------------------------------- Issue Type: Enhancement (was: Bug) > Try to have XTS enabled in standalone-full.xml > ---------------------------------------------- > > Key: JBTM-1523 > URL: https://issues.jboss.org/browse/JBTM-1523 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Application Server Integration, XTS > Reporter: Paul Robinson > Fix For: 5.0.0.Final > > > The problem is that XTS currently increases boot time by about 50%. Therefore it has to live in its own configuration. > If we can reduce this boot cost, we may be able to get it included in standalone-full.xml. > I think the main problem is the time it takes to register all the XTS Web Service endpoints. -- 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-1818) JacORBGenericRecoveryCreatorUnitTest fails as implname property has not been set

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1818?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1818: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/363 > JacORBGenericRecoveryCreatorUnitTest fails as implname property has not been set > -------------------------------------------------------------------------------- > > Key: JBTM-1818 > URL: https://issues.jboss.org/browse/JBTM-1818 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS, Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.M4 > > > Moving the class seems to have made the test fail due to the following warning: > 144 [main] ERROR jacorb.poa - Cannot create a persistent poa. The implname property has not been set. > Jul 02, 2013 9:46:53 PM com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit getRCPOA > WARN: ARJUNA022081: Failed to create poa for recoverycoordinators > org.omg.PortableServer.POAPackage.InvalidPolicy: IDL:omg.org/PortableServer/POA/InvalidPolicy:1.0 > at org.jacorb.poa.POA.create_POA(Unknown Source) > I have looked in the code and there is an @BeforeClass @AfterClass pair ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/recovery/RecoveryEnablementUnitTest.java which set this property. This does not operate as the author expected. The property is indeed set before TestBase has chance to initialize the orb, however the class is not unloaded by JUnit until after the run, hence why the order of when JacORBGenericRecoveryCreatorUnitTest is ran is important. Presumably before it was being run after RecoveryEnablementUnitTest, whereas now it is before. -- 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 July 2013