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

[Brian Stansberry (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBAS-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBAS-6584:
-----------------------------------

    Fix Version/s: JBossAS-5.1.1.GA
                       (was: JBossAS-5.1.0.GA)


Deferring to 5.1.1. Jason and I agree that the point of these tests is to catch JBoss problems, not JDK or OS ones. So we are going to limit these to their own hudson task that executes on a reliable JDK/OS combo.

> 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.1.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