Hello Clebert, should the second sample on the wiki page not contain SoftReference reference = new SoftReference(x); instead of WeakReference reference = new WeakReference(x); ?
Regards, Heinz On 8/7/07, Clebert Suconic <[EMAIL PROTECTED]> 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. > > > 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 > > Niall Pemberton wrote: > > On 8/7/07, Clebert Suconic <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > >>> Date: Aug 7, 2007 2:36 AM > >>> Subject: Re: Circular Reference on WeakHashMap > >>> To: Clebert Suconic <[EMAIL PROTECTED]> > >>> > >>> > >>> On 8/7/07, Clebert Suconic <[EMAIL PROTECTED]> wrote: > >>>> The solution seems simpler than I thought though... > >>>> > >>>> After looking at the report again... > >>>> [EMAIL PROTECTED] > >>>> > >>>> 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 <[EMAIL PROTECTED]> 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. > >>>>> > >>>>>> [EMAIL PROTECTED] > >>>>>> !--- [EMAIL PROTECTED] > >>>>>> !--- !--- class sun.reflect.GeneratedConstructorAccessor38 > >>>>>> !--- !--- !--- [Ljava.lang.Object;@10800875 > >>>>>> !--- !--- !--- !--- [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- !--- class > >>>>>> sun.reflect.GeneratedConstructorAccessor38 > >>>>>> !--- !--- !--- !--- !--- !--- !--- class java.lang.Class > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> [Ljava.util.HashMap$Entry;@28236766 > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> [EMAIL PROTECTED] > >>>>>> !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- !--- > >>>>>> !--- [EMAIL PROTECTED] > >>>>>> !---!---!---!---!---!---!---!---!---!---!---!---!---!---!---!--- > >>>>>> FieldReference private java.lang.Object > >>>>>> [EMAIL PROTECTED] > >>>>>> 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: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
