Re: [Springframework-developer] Cleanup of context resources on webapp reload

[<jue...@we...>]

Guillaume,
=20
I've prototypically added an Introspector.flushCaches call to context =
shutdown: I don't see any difference in the profiler. That's not too =
surprising, as the originally leaking classes are not managed by beans =
facilities in the first place: for example, SQLErrorCodesFactory, which =
is just used internally by SQLErrorCodeSQLExceptionTranslator.
=20
Of course, since my changes from a week ago, those classes don't leak =
anymore, as they hold their singleton instance in a WeakReference now... =
I still don't understand why this is necessary, but I'm 100% sure that =
it does make a difference on both Sun JDK 1.4.2 and Sun JDK 1.3.1. I've =
also tried various GC configuration options - always the same effect.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Guillaume Poirier
Gesendet: Sa 29.05.2004 06:12
An: spr...@li...
Betreff: Re: [Springframework-developer] Cleanup of context resources on =
webapp reload



I experimented some more about this cleanup issue, and I was able to =
narrow
down the problem to the caching done by the java.beans.Introspector.  It
stores the BeanInfo instances in a WeakHashMap, but in that Map
implementation, only the keys uses WeakReference, the values are stored =
with
hard references since BeanInfo has an hard reference on the class it =
gives
info about (indirectly through BeanDescriptor and others), any time
Introspector.getBeanInfo(Class) is used, that class and it's static =
members
will not ever be able to be garbage collected.  I kind of remember =
someone
mentioning something related to this in the mailling list, but I cannot =
find
the mail.  I wonder if there's other case where the java[x] classes =
might
have an hard reference on a class or its instances.  A fix for this
particular problem is to have a ServletContextListener call
Introspector.flushCaches() when the context is destroyed.

It seems like a known issue at Sun :

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4291376
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4730581
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D4809008

So, unless I'm missing something here, that means fixes like using
synchronization and WeakReference on singleton probably won't help much =
if
at all.  The only way that I can see for a class not to be gargage =
collected
when no more active thread use it, is if another ClassLoader has an hard
reference to the class instance, or an instance of that class.  Having =
the
class itself have an hard reference on a its own singleton has no =
effect,
it's a circular reference that will not prevent the class or the =
instance to
be gargabe collected when neither is being refered to by something else.

Guillaume




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer