]
Mike Millson commented on JBAS-2299:
------------------------------------
I found the issue with the notifcation listener. It was importing
com.sun.org.apache.commons.beanutils.MappedPropertyDescriptor from jsf-impl.jar instead of
org.apache.commons.beanutils.MappedPropertyDescriptor from commons-beanutils.
After this change, the notification listener removed commons-beanutils from paths from GC
root. I did get OOME, but with a different paths from GC roots to classloader.
Earlier analysis about the patched commons-beanutils was not quite right. With it I also
get OOME, but the test continues to deploy/undeploy. The heap dump is the same as when the
notification listener is used, commons-beanutils is not in paths from GC roots. It looks
like the patched commons-beanutils and the notification listener are equal in resolving
the commons-beanutils leak.
OutOfMemory error when repetatively deploying and undeploying with 10
minute interval
-------------------------------------------------------------------------------------
Key: JBAS-2299
URL:
http://jira.jboss.com/jira/browse/JBAS-2299
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.3RC2
Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
Reporter: Amar Syed
Assigned To: Clebert Suconic
Attachments: commons-beanutils-1.8.0-SNAPSHOT.jar, commons-beanutils.jar,
commons-digester-1.8.jar, Data.txt, deploy-undeploy.sh, paths-from-GC-roots.png,
SampleApp.ear, Sampleapp.zip, struts.jar, test-jbas-2299.tar.gz,
UndeploymentNotificationListener.java, UndeploymentNotificationListenerMBean.java
Time Spent: 2 hours
Remaining Estimate: 0 minutes
Using a manual copy and delete mechanism with the server\default\deploy folder the sample
ear (attached) caused an outofmemory error eventually after 90 repetitions.
The min and max heap settings were configured as : -Xms128m -Xmx512m
The time delay after dropping/deploying the ear at each repetition was set to 10 minutes
after which the ear is deleted/undeployed followed by a 10 second sleep till the next
deploy cycle.
I find this behaviour strange because
http://jira.jboss.com/jira/browse/JBAS-1319 is
supposed to have fixed this issue.
The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with
url null
2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository,
repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@e51e50,
cl=org.jboss.mx.loading.UnifiedClassLoader3@c90207{ url=null ,addedOrder=0}
2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw
error
java.lang.OutOfMemoryError
2005-09-24 06:04:33,057 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]]
StandardWrapper.Throwable
java.lang.OutOfMemoryError
2005-09-24 06:04:33,057 ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]]
Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
java.lang.OutOfMemoryError
2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with
url null
The following two jars were added to the server\default\lib folder.
commons-validator.jar --- version 1.1.3
struts.jar ---- version 1.2.4
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: