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 {

   } finally {

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

Reply via email to