[infinispan-dev] Tests failing: ports shared across modules

[Sanne Grinovero]

Hello,
Looking into hudson's tests on
http://hudson.jboss.org/hudson/view/Infinispan/job/Infinispan-trunk-JDK6-tcp
it appears the number of failed tests change from build to build even
by documentation changes or other unrelated changes.
Two examples:

Build #1031 :
Changes: Typos in javadocs
Test Result (4 failures / -1)
a javadoc change fixed a test?

Build #1033 :
Changes: [ISPN-301] (Closing the Lucene Directory will close the cache too)
Test Result (8 failures / +2)
So while I only changed something related to Lucene, the failures in
core increased?

In some of the test errors you can find evidence of communication
between test scenarios, like these:
http://hudson.jboss.org/hudson/view/Infinispan/job/Infinispan-trunk-JDK6-tcp/org.infinispan$infinispan-lucene-directory/1025/testReport/(root)/TestSuite/createBeforeClass/
http://hudson.jboss.org/hudson/view/Infinispan/job/Infinispan-trunk-JDK6-tcp/org.infinispan$infinispan-tree/1025/testReport/org.infinispan.api.tree/SyncReplTxTest-createBeforeClass/org_infinispan_api_tree_SyncReplTxTest_createBeforeClass/

first one from the Lucene module, second from the Tree module: they
both have the node vmg22.mw.lab.eng.bos.redhat.com-42912
and are complaining about an unexpected number of participants.
Looking into the other errors it always looks like as "someone else"
changed the cache, but there's no evidence, so I think we should solve
the isolation problem first?

Both stacktraces show that they're using
org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:137)
to setup the caches, so it doesn't appear to be a problem with these
two testcases.

This kind of interactions don't seem to happen inside a single module,
could it be a classloader problem? A static threadlocal defines the
jgroups port to use, but it's "static" in a per-module world, instead
of globally static?
I've added some logging to
org.infinispan.test.fwk.JGroupsConfigBuilder, 2 snippets of the
result:
[org.infinispan.test.fwk.JGroupsConfigBuilder] (pool-1-thread-1) TCP
bind_port:7900 ClassLoder:org.apache.maven.surefire.booter.IsolatedClassLoader at 2e93d13f
[...many lines..]
[org.infinispan.test.fwk.JGroupsConfigBuilder] (pool-1509-thread-10)
TCP bind_port:7900
ClassLoder:org.apache.maven.surefire.booter.IsolatedClassLoader at 2d1a2259

I see the two classloaders being different, and while the threads are
different they are sharing the same bind_port 7900.

Looking into http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html
It looks like from Surefire 2.4.3 the default is to use a shared
system classloader, but there's a little warning at the bottom of page
about not being possible to not isolate the classloader while using
forkMode=none

ideas?

P.S. where can I get the sources of maven-surefire-plugin version2.4.3-JBOSS ?

Cheers,
Sanne