It could be as simple as your ThreadLocal, in addition to that, this could also 
be caused by others.

The class-loader problem has bugged many people. JavaOne07 had this late 
evening FOB session on the topic, and a lot of people showed up, looking for 
answer.

In short, 'An object can only be garbage collected if the object is 
unreachable'.
A sample code:

import java.util.logging.*;

public class your_class {
   private static final Level CUSTOMLEVEL = new Level("test", 555) {};
   ....
        Logger.getLogger("test").log("CUSTOMLEVEL, "something");
   ....
};

Since CUSTOMLEVEL contains java.util.logging.Level.INFO (SEVERE, etc), and they 
are 'reachable' from other part of JVM, so your_class is not garbage collected.

On that FOB session, Edward used JHat to trace PermGen leaks, and found 5-6 
violations in that application server and a couple of places in the user 
application. A note to Caucho engineers: that case study was not based on Resin.

You can find these discussions from the blogs of two Sun engineers who 
presented this FOB:

http://blogs.sun.com/fkieviet
http://blogs.sun.com/edwardchou

one of the good articles is on Frank's blog:
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java



> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Scott Ferguson
> Sent: Monday, June 11, 2007 9:12 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Application Memory Profiling
>
>
>
> On Jun 11, 2007, at 3:00 AM, Daniel López wrote:
>
> >
> > Something similar happens with com.caucho.xml.Xml: I start with 2
> > instances, one referenced from a class of mine and another from
> > java.lang.ThreadLocal. After a restart I get 2 instances referenced
> > from
> > java.lang.ThreadLocal. Another restart and I have 3 referenced from
> > java.lang.ThreadLocal... In this case, the problem seems to be a
> > growing
> > number of instances from
> org.apache.xml.utils.XMLReaderManager... that
> > are themselves related to the aforementioned
> > com.caucho.loader.EnvironmentClassLoader.
>
> Do you know what is holding the ThreadLocal references?
>
> This definitely looks like a threading/ThreadLocal issue.  There have
> been libraries which have neglected to clear the ThreadLocals
> properly, which will cause major problems with garbage collection and
> classloading.   That would be the first thing to look at.
>
> ThreadLocal needs to be used with the following pattern:
>
>    ThreadLocal _local = new ThreadLocal();
>
>    ...
>
>    Object oldValue = _local.get();
>    try {
>      _local.set(newValue);
>
>      ...
>    } finally {
>      _local.set(oldValue);
>    }
>
> If the application forgets the second set, then the oldValue will not
> be garbage collected.
>
> >
> > So my question would be if anybody has run into similar
> issues or has
> > any idea what could be causing the proliferation of
> > com.caucho.loader.EnvironmentClassLoader instances. I
> suspect it might
> > be that some library is keeping a reference to the
> classloader through
> > some daemon thread that is not being properly initialised when the
> > context is restarted.
> >
> > Any hints on how to further debug this issue? Any similar
> experience?
>
> Look for the ThreadLocal reference.  Also, double check that there
> isn't a daemon thread that isn't properly closed on restart.
>
> -- Scott
>
> > Thanks,
> > D.
> >
> >
> >
> >
> >
> > _______________________________________________
> > resin-interest mailing list
> > resin-interest@caucho.com
> > http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>


_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to