The test case ClusteredClassloaderLeakUnitTest is repeatedly timing out, even when the junit.timeout for the test is extended from 180 secs (default) to 800 secs.
This test seems to pass OK on RHEL with the usual timeout.

This test deploys a war/ejb/ear, makes a few invocations, and then undeploys the war/ejb/ear. While doing so, it keeps a record of the classloaders deployed via an MBean ClassloaderTracker which is deployed before the tests start. It uses the record of classloaders registered to check that (ii) all classloaders are present when they should be (after deployment) and (ii) all classloaders are absent when they should be (after undeployment).

The sequence of steps performed fror the war version of the test are:

• checkCleanKeys
• deployComponent
• makeWebRequest
• checkRegistration
• undeployComponent
• flushSecurityCache
• checkClassloaderRelease

The test currently performs two tests involving war deployments (tests for the other deployments have been commented out): testSimpleWar, testNoPassivationWar.

The test testSimpleWar generally passes, after a substantial wait at checkClassloaderRelease.
The test testNoPassivatioWar regularly hangs when it reaches checkClassloaderRelease.

I'm not sure of this is a bug, as the test times out and does not fail an assertion; however, even tripling the time allowed for the test does not help.
Something seems to be untoward in the method checkClassloaderRelease, which calls ClassloaderStore.getClassloader with the forceGC parameter set to true, and it is untoward only on these platforms.

This test has been placed at the end of the testsuite, as it generally modifies the state of the servers so that they also will not shut down properly. This allows the testsuite to complete the generalion of reports and not waste a test run.