<div class="gmail_quote">On Mon, Jun 25, 2012 at 5:58 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
the testsuite on master is regularly hanging for me, and I get all<br>
threads waiting while this one is spinning on the put() operation.<br>
<br>
java.lang.Thread.State: RUNNABLE<br>
at java.util.HashMap.put(HashMap.java:374)<br>
at org.testng.SuiteRunner.runTest(SuiteRunner.java:320)<br>
at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)<br>
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)<br>
at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)<br>
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)<br>
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)<br>
at java.lang.Thread.run(Thread.java:662)<br>
<br>
<br>
Clearly the parallel testsuite is not synchronizing properly on the<br>
HashMap, this looks like a TestNG bug.<br>
<br>
So I've tried to update to latest 6.5.2; from the Changelog this looks<br>
like fixed, as is a very long list of other issues; not least<br>
<br>
"Fixed: Skipped tests were not always counted"<br>
<br>
which might address the strange numbers we had noticed on Jenkins.<br>
<br></blockquote><div><br>Excellent!<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But I'm still unable to run the full testsuite; what follows are the<br>
reasons from several different attempts:<br>
<br>
<br>
testng-SyncBasicSingleLockOptimisticTest) Exiting because<br>
lock.singlelock.SyncBasicSingleLockOptimisticTest has NOT shut down<br>
all the cache managers it has started !!!!!!!<br>
<br>
testng-SyncBasicSingleLockOptimisticTest) Exiting because<br>
lock.singlelock.SyncBasicSingleLockOptimisticTest has NOT shut down<br>
all the cache managers it has started !!!!!<br>
<br>
(testng-BasicSingleLockOptimisticTest) Exiting because<br>
lock.singlelock.BasicSingleLockOptimisticTest has NOT shut down all<br>
the cache managers it has started !!!!!!!<br>
<br>
(testng-BasicSingleLockOptimisticTest) Exiting because<br>
lock.singlelock.BasicSingleLockOptimisticTest has NOT shut down all<br>
the cache managers it has started !!!!!!!<br>
<br>
(testng-SyncBasicSingleLockOptimisticTest) Exiting because<br>
lock.singlelock.SyncBasicSingleLockOptimisticTest has NOT shut down<br>
all the cache managers it has started !!!!!!!<br>
<br>
<br>
Looking into the BasicSingleLockOptimisticTest I'm not seeing how this<br>
could be possible, so I'm wondering if this could be a problem related<br>
to the TestNG update? Any thoughts?<br>
<br></blockquote><div><br>Galder and I saw the same thing with another test in Jenkins: <a href="https://issues.jboss.org/browse/ISPN-2117?focusedCommentId=12702926&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12702926" target="_blank">https://issues.jboss.org/browse/ISPN-2117?focusedCommentId=12702926&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12702926</a><br>
<br>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...<br>
</div></div><br>Cheers<br>Dan<br><br>