[
https://jira.jboss.org/jira/browse/JBAS-6584?page=com.atlassian.jira.plug...
]
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