[jboss-jira] [JBoss JIRA] Commented: (JBAS-6584) Clustered classloader leak test repeatedly times out on Solaris and HPUX

[Richard Achmatowicz (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12460098#action_12460098 ] 

Richard Achmatowicz commented on JBAS-6584:
-------------------------------------------

Short answer: Sun JDK 5.

On HPUX:

-bash-3.1$ uname -a
HP-UX dev24 B.11.23 U 9000/800 348814536 unlimited-user license
-bash-3.1$ java -version
java version "1.5.0.11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0.11-_07_nov_2007_10_59)
Java HotSpot(TM) Server VM (build 1.5.0.11 jinteg:11.07.07-09:52 PA2.0 (aCC_AP), mixed mode)
-bash-3.1$ hostname
dev24.qa.atl2.redhat.com

On Solaris:

-bash-3.00$ hostname
dev13
-bash-3.00$ uname -a
SunOS dev13 5.10 Generic_118855-15 i86pc i386 i86pc
-bash-3.00$ java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Server VM (build 11.0-b16, mixed mode)

The version listed here is JDK 6, but I was using JDK 5.


> Clustered classloader leak test repeatedly times out on Solaris and HPUX
> ------------------------------------------------------------------------
>
>                 Key: JBAS-6584
>                 URL: https://jira.jboss.org/jira/browse/JBAS-6584
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Clustering, Test Suite
>    Affects Versions: JBossAS-5.0.1.GA
>         Environment: Solaris, HPUX platforms
>            Reporter: Richard Achmatowicz
>            Assignee: Brian Stansberry
>             Fix For: JBossAS-5.1.0.GA
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira