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

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. 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? Cheers, Sanne