Re: [infinispan-dev] Hanging testsuite / bug in TestNG?

On 25 June 2012 20:06, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > On Mon, Jun 25, 2012 at 5:58 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; > 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... Thanks Dan! Strange that this happens to me consistently on the same test.. do you know what is supposed to trigger this @AfterMethod failure? Is there a reference to the Surefire issue?