[
http://jira.jboss.com/jira/browse/JBAS-1319?page=comments#action_12316790 ]
Clebert Suconic commented on JBAS-1319:
---------------------------------------
Basically I have created a profiler for analyzing this bug.
I had to do that because I had to cross information on the classloader to find
where we could have references to any specific classloader.
By definition (at least I read that somewhere on Sun's website, I think this
was JVM spec) a class is only unloaded if there isn't any reference in the
memory, plus you don't have any references to the classloader.
So, I'm not sure if this will release classes at GC operations, but this is the
only way it could work.
So, first the analysis I've made: (open the file analysis.zip)
I - step1-classes.htm
You will see all the classes I have loaded. In particular I deployed a WAR
application twice (in particular JBoss-profiler.war).
You will see Lorg/jboss/profiler/util/SPYConsts without any instances. I
also navigated to references in both ways. Nothing holding.
II - step2-classesAtClassLoader.
I detailed the classLoader that loaded Lorg/jboss/profiler/util/SPYConsts;.
It's kind of weird but that same ClassLoader also loaded FastHashMap and
PropertyMessageResourcesFactory. Well... maybe this was because of Struts as I
use it in the profiler. (not sure, but maybe this is not even related)
III - step3-references-toClassLoader.htm
I think (or at least I hope) this is the root cause:
You have some references to the classLoader to its classes (what is
expected), but you have also 34 thread references through
Lorg/apache/tomcat/util/threads/ThreadWithAttribute. These are 34 references to
that classloader through a single instance of ThreadWithAttribute.
A Thread reference means a reference that sits in the stack-trace on the
VM. (In another words, the thread, what could be even a ThreadLocalData or a
property in a Thread).
I read its source code and there is an array on that thread.
Well... I don't have resources to go beyond that right now, but at least I
wanted to leave this analysis registered and maybe someone could have some
light on this.
> redeploy causes OutOfMemoryError
> --------------------------------
>
> Key: JBAS-1319
> URL: http://jira.jboss.com/jira/browse/JBAS-1319
> Project: JBoss Application Server
> Type: Bug
> Components: JMX
> Versions: JBossAS-4.0.1 Final
> Environment: JBoss 4.0.1 running on fedora core 3, using jdk 1.5.0
> Reporter: Matthew Todd
> Assignee: Clebert Suconic
> Attachments: analysis.zip
>
>
> Constant redployment, even of a simple web application eventually causes an
> OutOfMemoryError in JBoss.
> To duplicate, keep on copying a .war package into a servers hot deploy
> directory. Eventually an OutOfMemoryError occurs.
> This is especially dangerous when running as a cluster, as when the node is
> restarted, it is unable to join the cluster again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
