On Jun 11, 2007, at 10:11 AM, Gary Zhu wrote:

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

True, but in this case, Daniel has noticed the extra ThreadLocal as  
the object holding the link in the profile, so it's a good place to  
start looking.

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

By the way, this is a bug in java.util.logging.Level.  The  
application code would be fine if it wasn't for the JDK bug.

The general rule is: never store an object from a child classloader  
context in a parent classloader context unless you use WeakReferences.

It's the main reason why Singletons are dangerous.

ThreadLocal is an instance of this problem, because it's essentially  
storing the object in the root classloader context.

-- Scott

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



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

Reply via email to