commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Stansberry <bes_commons_...@yahoo.com>
Subject Re: [beanutils] [logging]j2ee unit tests added: memory leak demonstrated (?)
Date Wed, 16 Mar 2005 08:21:54 GMT
Replying to myself:
--- Brian Stansberry <bes_commons_dev@yahoo.com>
wrote:
> Simon,
> 
> I spent some time last night looking at this, mostly
> just familiarizing myself with how beanutils works
> so
> I could understand the problem.
> 
> I think you're right to be concerned about JCL, as
> from what I can see the two applications are very
> similar:
> 
> "weak-keyed" map (aka "WeakMap") held statically by
> class loaded by container (beanutils:
> BeanUtilsBean.beanByClassLoader; JCL:
> LogFactory.factories).
> 
> WeakMap key is the TCCL.
> 
> WeakMap value is a class loaded by container, but
> value is instantiated while component loader is the
> TCCL (beanutils: BeanUtilsBean; JCL:
> LogFactoryImpl).
> 
> WeakMap value holds another map (aka "StrongMap")
> (beanutils:
> BeanUtilsBean.convertUtilsBean.converters;
> JCL: LogFactory.instances)
> 
> StrongMap value is a class loaded by the component
> loader (beanutils: FloatConverter; JCL:
> Log4jLogger). 
> Class implements an interface loaded by the
> container
> loader (beanutils: Converter; JCL: Log).  This
> reference is likely what's preventing release of the
> classloader in beanutils.
> 

After exploring more with the JCL code, I'm almost
certain the reference to FloatConverter in
BeanUtilsBean.convertUtilsBean.converters is what's
causing o.a.c.beanutils.converter.MemoryTestCase to
fail.

When I wrote before, I only said "likely" because I
couldn't see why JCL wouldn't always have the same
failure, and I had tests where it didn't.  But I've
now created tests where it does (see below); tests
that are basically analogous to MemoryTestCase.

> I noticed that the JCL unit test I wrote for memory
> release has a weakness in that it doesn't add the
> Log
> instance to LogFactoryImpl.instances.  I noticed
> that
> a week ago and added the required call so I could
> check the tests still passed.  They did.  But,
> didn't
> get a chance to clean up the code and submit a
> proper
> patch for the tests.  My bad :(
> 
> I'll for sure do that tonight, plus add some more
> assertions like the beanutils test has in order to
> ensure that classes are being loaded by the intended
> loader.  This should either surface a problem in JCL
> or help shed some light on the beanutils problem.
> 

Will have to be another day before I submit a patch
for the JCL tests (after midnight now).  But, I've
found in JCL the classloader is not released when
LogFactoryImpl is loaded by a parent loader and the
Log wrapper is loaded  by a child.  I've identified
two basic configurations where this might happen:

1) Parent-first delegation model, where the parent has
commons-logging-api.jar, child has commons-logging.jar
and child wants to use Log4j or Avalon (or some custom
Log implementation).

2) Child-first delegation model that uses the
configuration I proposed in my "Further Analysis"
document; i.e. where the parent has
commons-logging-api-xxx.jar, child has
commons-logging-impl.jar and child wants to use Log4j
or Avalon.


Brian


		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message