On Mon, Jun 25, 2012 at 5:58 PM, Sanne Grinovero <sanne(a)infinispan.org>wrote:
Hi all,
the testsuite on master is regularly hanging for me, and I get all
threads waiting while this one is spinning on the put() operation.
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.put(HashMap.java:374)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:320)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
at
org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Clearly the parallel testsuite is not synchronizing properly on the
HashMap, this looks like a TestNG bug.
So I've tried to update to latest 6.5.2; from the Changelog this looks
like fixed, as is a very long list of other issues; not least
"Fixed: Skipped tests were not always counted"
which might address the strange numbers we had noticed on Jenkins.
Excellent!
But I'm still unable to run the full testsuite; what follows are
the
reasons from several different attempts:
testng-SyncBasicSingleLockOptimisticTest) Exiting because
lock.singlelock.SyncBasicSingleLockOptimisticTest has NOT shut down
all the cache managers it has started !!!!!!!
testng-SyncBasicSingleLockOptimisticTest) Exiting because
lock.singlelock.SyncBasicSingleLockOptimisticTest has NOT shut down
all the cache managers it has started !!!!!
(testng-BasicSingleLockOptimisticTest) Exiting because
lock.singlelock.BasicSingleLockOptimisticTest has NOT shut down all
the cache managers it has started !!!!!!!
(testng-BasicSingleLockOptimisticTest) Exiting because
lock.singlelock.BasicSingleLockOptimisticTest has NOT shut down all
the cache managers it has started !!!!!!!
(testng-SyncBasicSingleLockOptimisticTest) Exiting because
lock.singlelock.SyncBasicSingleLockOptimisticTest has NOT shut down
all the cache managers it has started !!!!!!!
Looking into the BasicSingleLockOptimisticTest I'm not seeing how this
could be possible, so I'm wondering if this could be a problem related
to the TestNG update? Any thoughts?
Galder and I saw the same thing with another test in Jenkins:
https://issues.jboss.org/browse/ISPN-2117?focusedCommentId=12702926&p...
To reiterate here, there was/is another concurrency issue in the
maven-surefire-plugin that caused it to sometimes skip @AfterMethod methods
after a failure. Galder upgraded the plugin to 2.12 hoping it would fix the
problem, but if you're still seeing I guess that wasn't enough...
Cheers
Dan