commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <csuco...@redhat.com>
Subject Re: Fwd: Circular Reference on WeakHashMap
Date Wed, 08 Aug 2007 02:10:47 GMT
I just added the testcase to this JIRA:

https://issues.apache.org/jira/browse/BEANUTILS-291


And it replicated the problem as expected... The test fails as 
expected... I have done some double checks, and it is the same scenario 
as it would happen on any application server.


Niall Pemberton wrote:
> On 8/7/07, Clebert Suconic <csuconic@redhat.com> wrote:
>>  > Yes, but that reference can be garbage collected - so would have to
>>  > handle that as well. In this instance each AbstractConverter
>>  > implementation only ever returns the same value - so I think its
>>  > simpler to remove the class reference - for example in
>>  > IntegerConverter it would just have:
>>
>> no... it won't...
>>
>> As long as the ClassLoader is referenced somewhere, the WeakReference
>> won't die. This is different on Reflection, as any class.getMethod()
>> would return a brand new Method.
> 
> Ahhh OK.
> 
>> You probably have a WeakHashMap<ClassLoader, Cache>
>>
>>
>> When any application server releases the reference to classLoader, your
>> WeakhashMap will automatically remove the element on the map, as long as
>> you don't have Circular references to ClassLoader on the value:
>>
>> There is a WIKI page I wrote about this, where I have written some
>> information about it:
>>
>> http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLeakage
> 
> Great, thanks I'll take a look.
> 
> Niall
> 
>> Niall Pemberton wrote:
>>> On 8/7/07, Clebert Suconic <csuconic@redhat.com> wrote:
>>>>  > Yes it does (thru' AbstractConveter which it extends) - I can remove
>>>>  > that reference completely by just making the getDefaultType() method
>>>>  > abstract and having each implementation implement it.
>>>>  >
>>>>
>>>> Just an idea... You could just have the Abstract class holding a
>>>> WeakReference and then:
>>>>
>>>> WeakReference clazz;
>>>>
>>>> public void setClazz(Class clazz)
>>>> {
>>>>    this.clazz = new WeakReference(clazz);
>>>> }
>>>>
>>>> public Class getClazz()
>>>> {
>>>>     return (Class) clazz.get();
>>>> }
>>> Yes, but that reference can be garbage collected - so would have to
>>> handle that as well. In this instance each AbstractConverter
>>> implementation only ever returns the same value - so I think its
>>> simpler to remove the class reference - for example in
>>> IntegerConverter it would just have:
>>>
>>>     protected Class getDefaultType() {
>>>         return Integer.class;
>>>     }
>>>
>>> Niall
>>>
>>>> Niall Pemberton wrote:
>>>>> Woops, should have gone to dev@ list
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Niall Pemberton <niall.pemberton@gmail.com>
>>>>> Date: Aug 7, 2007 2:36 AM
>>>>> Subject: Re: Circular Reference on WeakHashMap
>>>>> To: Clebert Suconic <csuconic@redhat.com>
>>>>>
>>>>>
>>>>> On 8/7/07, Clebert Suconic <csuconic@redhat.com> wrote:
>>>>>> The solution seems simpler than I thought though...
>>>>>>
>>>>>> After looking at the report again...
>>>>>> org.apache.commons.beanutils.converters.ClassConverter@22616909
>>>>>>
>>>>>> ClassConverter  probably has a reference to Class... I thought this
was
>>>>>> a reflection object.
>>>>>>
>>>>>> It should be WeakReference<Class>.
>>>>> Yes it does (thru' AbstractConveter which it extends) - I can remove
>>>>> that reference completely by just making the getDefaultType() method
>>>>> abstract and having each implementation implement it.
>>>>>
>>>>>> And... inspect your code for any other reflection usages.
>>>>> OK when I get back I was going to have a play with JVMTIInterface - looks
good.
>>>>>
>>>>> Niall
>>>>>
>>>>>> Niall Pemberton wrote:
>>>>>>> On 8/6/07, Clebert Suconic <csuconic@redhat.com> wrote:
>>>>>>>> I have been investigating WeakHashMaps on BeanUtils 1.8 as
part of a
>>>>>>>> investigation on this:
>>>>>>>>
>>>>>>>> http://jira.jboss.com/jira/browse/JBAS-2299
>>>>>>> Thanks for getting back to us so quickly.
>>>>>>>
>>>>>>>> (Which is not actually an issue with JBAS, but an issue when
using
>>>>>>>> BeanUtils as part of the classPath).
>>>>>>>>
>>>>>>>> There is a circular reference on the WeakHashMap, The WeakHashMap
will
>>>>>>>> have the ClassLoader as the key, and it will have a reference
back to
>>>>>>>> the Key from one of the Reflection objects. This doesn't
work! (Please..
>>>>>>>> no discussions about this point.. if you don't believe me,
do some
>>>>>>>> testing with simple stuff before discussing this and come
back to me
>>>>>>>> only after that)
>>>>>>> OK I will.
>>>>>>>
>>>>>>>> org.jboss.web.tomcat.service.WebAppClassLoader@16334564
>>>>>>>> !--- sun.reflect.DelegatingClassLoader@27651708
>>>>>>>> !--- !--- class sun.reflect.GeneratedConstructorAccessor38
>>>>>>>> !--- !--- !--- [Ljava.lang.Object;@10800875
>>>>>>>> !--- !--- !--- !--- java.util.Vector@838806
>>>>>>>> !--- !--- !--- !--- !--- sun.reflect.DelegatingClassLoader@27651708
>>>>>>>> !--- !--- !--- !--- !--- !--- class
>>>>>>>> sun.reflect.GeneratedConstructorAccessor38
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- class java.lang.Class
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !---
>>>>>>>> org.apache.commons.beanutils.converters.ClassConverter@22616909
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>>>> org.apache.commons.beanutils.converters.ArrayConverter@18888821
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>>>> org.apache.commons.beanutils.converters.ConverterFacade@13619754
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>>>> java.util.HashMap$Entry@32434103
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
>>>>>>>> [Ljava.util.HashMap$Entry;@28236766
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
!---
>>>>>>>> java.util.HashMap@14997495
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
!--- !---
>>>>>>>> org.apache.commons.beanutils.ConvertUtilsBean@2016953
>>>>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !---
!--- !---
>>>>>>>> !--- org.apache.commons.beanutils.BeanUtilsBean@30487951
>>>>>>>> !---!---!---!---!---!---!---!---!---!---!---!---!---!---!---!---
>>>>>>>> FieldReference private java.lang.Object
>>>>>>>> java.util.WeakHashMap$Entry.value=java.util.WeakHashMap$Entry@23775534
>>>>>>>> Detail
>>>>>>> I'm not familiar with JBoss's JVMTIInterface or its output -
and it
>>>>>>> seems to be somewhat messed up in posting here - so I've (hopefully)
>>>>>>> cleaned it up and re-posted in a Jira ticket I've opened for
this
>>>>>>> here:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/BEANUTILS-291
>>>>>>>
>>>>>>>> I don't know if I'm preaching to the choir, but just in case
this is new
>>>>>>>> information to someone... you should aways keep Reflection
referenced as
>>>>>>>> SoftReferences (if you really have to). Reflection is aways
a new object
>>>>>>>> so a WeakReference is too weak.
>>>>>>> Preach away - I have no great knowledge of this stuff.
>>>>>>>
>>>>>>>> On JBossSerialization I have solved this using an interesting
way. I
>>>>>>>> called it PersistentReference. I'm using SoftReferences,
and keeping the
>>>>>>>> information to recreate it case the SoftReference is cleared:
>>>>>>>>
>>>>>>>> http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3
>>>>>>>>
>>>>>>>>
>>>>>>>> And also... you guys should write a testcase to validate
if the Caching
>>>>>>>> is being cleared. (I don't know if you have one).
>>>>>>>>
>>>>>>>> http://anonsvn.jboss.org/repos/jbossserialization/trunk/tests/org/jboss/serial/memory/MemoryLeakTestCase.java
>>>>>>>>
>>>>>>>> You don't need to use the jboss-profiler API for this.. just
create a
>>>>>>>> WeakReference to a new ClassLoader, and validate if it was
released at
>>>>>>>> the end after some exercizing some code on this caching.
You will
>>>>>>>> probably need to fill your memory almost to 100% on the test
as
>>>>>>>> SoftReference are only gone when the memory is low.
>>>>>>> Unfortunately I'm away on holiday soon for 3 weeks (12th August
to 2nd
>>>>>>> September) - so unless someone else picks this up - ii don't
have time
>>>>>>> to look at this until after that. Do you mind if we move the
>>>>>>> discussion over to that Jira ticket I opened though?
>>>>>>>
>>>>>>> Niall
>>>>>>>
>>>>>>>> Clebert Suconic
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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


Mime
View raw message