[beanutils] j2ee unit tests added: memory leak demonstrated (?)

[Simon Kitching <sk...@apache.org>]

Hi,

I've just added a unit test o.a.c.beanutils.converter.MemoryTestCase.
This test case currently fails, demonstrating (I believe) that there is
a serious memory leak in beanutils in j2ee-like environments when
components are "undeployed".

The tests show that if a Converter is registered while
Thread.getContextClassLoader is set to a component-specific classloader,
then when the component is "undeployed" that classloader cannot be
garbage-collected.

The problem is: I can't spot what is *causing* this bug. It would be
great if someone else could have a look too.

Given the new code in commons-logging that is intended to address a
similar issue, I think this is worth resolving before releasing
commons-logging 1.0.5....

Regards,

Simon


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

Re: [beanutils] j2ee unit tests added: memory leak demonstrated (?)

[Brian Stansberry <be...@yahoo.com>]

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.

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.

Regards,
Brian

--- Simon Kitching <sk...@apache.org> wrote:

> Hi,
> 
> I've just added a unit test
> o.a.c.beanutils.converter.MemoryTestCase.
> This test case currently fails, demonstrating (I
> believe) that there is
> a serious memory leak in beanutils in j2ee-like
> environments when
> components are "undeployed".
> 
> The tests show that if a Converter is registered
> while
> Thread.getContextClassLoader is set to a
> component-specific classloader,
> then when the component is "undeployed" that
> classloader cannot be
> garbage-collected.
> 
> The problem is: I can't spot what is *causing* this
> bug. It would be
> great if someone else could have a look too.
> 
> Given the new code in commons-logging that is
> intended to address a
> similar issue, I think this is worth resolving
> before releasing
> commons-logging 1.0.5....
> 
> Regards,
> 
> Simon
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

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