springframework-developer

Re: [Springframework-developer] CachedIntrospectionResults classCache leak

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

If this happens with Spring 1.0.2, it is typically caused by *other* =
code that causes a leak. The ClassLoader is then still around, also =
showing Spring classes like CachedIntrospectionResults. This is not =
Spring's fault: Spring classes just keep hanging around as a side =
effect.
=20
Try calling "java.beans.Introspector.flushCaches()" on application =
shutdown. This is a typical source of such leaks: The JavaBeans =
Introspector might still refer to application classes. This is not =
caused by Spring: It's rather other libraries that use the Introspector, =
for example Quartz.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Do 15.07.2004 14:38
An: spr...@li...
Betreff: Re: [Springframework-developer] CachedIntrospectionResults =
classCache leak



Claudio

What version of Spring is your analysis against?

R

----- Original Message -----
From: "Claudio D'Angelo" <cla...@ob...>
To: <spr...@li...>
Sent: Thursday, July 15, 2004 10:26 AM
Subject: [Springframework-developer] CachedIntrospectionResults =
classCache
leak


> Hi,
> I'm analyzing with OptimizeIt my web application:
> when I redeploy the application I note that instances of
> CachedIntrospectionResults still in memory and for any redeploy the
> instances raise.




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] CachedIntrospectionResults classCache leak

[Claudio D'A. <cla...@ob...>]

I've deployed the minimal application (see the spring's sample). There 
isn't Quarts, ibatis or hibernate. There is a controller with a test.jsp only.

I don't understand about memory leak, weark or soft referance but I've see 
that CachedIntrospectionResults is referenced 
by  CachedIntrospectionResults.classCache and there are 2 instances 
(org.springframework.context.support.ResourceBundleMessageSource and 
org.springframework.web.servlet.DispatcherServlet)


Where I can call the java.beans.Introspector.flushCaches()?

Please help. After 20 redeploy Tomcat goes in OutOfMemory and ELS craches

At 15.17 15/07/2004 +0200, you wrote:
>If this happens with Spring 1.0.2, it is typically caused by *other* code 
>that causes a leak. The ClassLoader is then still around, also showing 
>Spring classes like CachedIntrospectionResults. This is not Spring's 
>fault: Spring classes just keep hanging around as a side effect.
>
>Try calling "java.beans.Introspector.flushCaches()" on application 
>shutdown. This is a typical source of such leaks: The JavaBeans 
>Introspector might still refer to application classes. This is not caused 
>by Spring: It's rather other libraries that use the Introspector, for 
>example Quartz.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von 
>Rod Johnson
>Gesendet: Do 15.07.2004 14:38
>An: spr...@li...
>Betreff: Re: [Springframework-developer] CachedIntrospectionResults 
>classCache leak
>
>
>
>Claudio
>
>What version of Spring is your analysis against?
>
>R
>
>----- Original Message -----
>From: "Claudio D'Angelo" <cla...@ob...>
>To: <spr...@li...>
>Sent: Thursday, July 15, 2004 10:26 AM
>Subject: [Springframework-developer] CachedIntrospectionResults classCache
>leak
>
>
> > Hi,
> > I'm analyzing with OptimizeIt my web application:
> > when I redeploy the application I note that instances of
> > CachedIntrospectionResults still in memory and for any redeploy the
> > instances raise.
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer

Grazie e buon lavoro

----------
Claudio D'Angelo
Software Consultant
ObjectWay S.p.A.
Via G.A. Boltraffio 7
20159 Milano (MI)
http://www.objectway.it


-- 
La presente comunicazione potrebbe contenere informazioni riservate e/o
protette
da segreto professionale ed e' indirizzata esclusivamente ai destinatari della
medesima qui indicati. Se avete ricevuto per errore la presente comunicazione,
siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di
e-mail,
e a cancellare il presente messaggio dal Vostro sistema. E' strettamente
proibito
e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione,
copia
o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
ricevuta per errore o in violazione degli scopi della presente.
Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi
ed
e' risultato NON infetto.

Re: [Springframework-developer] CachedIntrospectionResults classCache leak

[Guillaume P. <gpo...@gl...>]

As Juergen pointed out, if you find a static member hasn't been garbage 
collected, it just means its ClassLoader cannot be garbage collected 
yet, the static member is not necessarly at fault there.  For an 
explanation of the current behavior, see below.

For the solution, you can use a ServletContextListener to call 
java.beans.Introspector.flushCaches() when the ServletContext is detroy 
(which causes the ClassLoader to be thrown away).

>                 if (results == null) {
>                         // can throw BeansException
>                         results = new CachedIntrospectionResults(clazz);
>                         boolean cacheSafe = isCacheSafe(clazz);
>                         if (logger.isDebugEnabled()) {
>                                 logger.debug("Class [" + 
> clazz.getName() + "] is " + (!cacheSafe ? "not " : "") + "cache-safe");
>                         }
> *                        classCache.put(clazz, new 
> WeakReference(results));
> *                }

Since Spring 1.0.2, the current code of this method is the following :

        if (results == null) {
            // can throw BeansException
            results = new CachedIntrospectionResults(clazz);
            boolean cacheSafe = isCacheSafe(clazz);
            if (logger.isDebugEnabled()) {
                logger.debug("Class [" + clazz.getName() + "] is " + 
(!cacheSafe ? "not " : "") + "cache-safe");
            }
            if (cacheSafe) {
                classCache.put(clazz, results);
            }
            else {
                classCache.put(clazz, new WeakReference(results));
            }
        }

What the isCacheSafe(Class) method does is check if the clazz's 
ClassLoader is the
same as CachedIntrospectionResults, or a parent of it.  Because what 
prevent garbage
collection of a ClassLoader A is if a class of a ClassLoader B that is 
not for garbage
collection has a reference on a class (or instance) of the ClassLoader 
A.  However, if
A is a parent of B (or B == A), then A cannot be collected anyway.  
Which is why if clazz
is considered "cacheSafe", no WeakReference is necessary, and in such 
case it improve
performance.  For example, if the class introspected is a JDK class, or 
a Spring class, its
ClassLoader can never be collected before the CachedIntrospectionResults 
class.

> I don't understand about memory leak, weark or soft referance but I've 
> see that CachedIntrospectionResults is referenced by  
> CachedIntrospectionResults.classCache and there are 2 instances 
> (org.springframework.context.support.ResourceBundleMessageSource and 
> org.springframework.web.servlet.DispatcherServlet)

I don't know what causes the ClassLoader to be retained, but you cannot 
easily know what is the cause, just knowning that singletons instances 
are still in the JVM only proves that the ClassLoader has not been 
garbage collected.  The problem is that something in a parent (or 
sibling) ClassLoader still has a reference on a Class of your webapp's 
ClassLoader.  The trick is to find what is.

Guillaume

Claudio D'Angelo wrote:

> I've deployed the minimal application (see the spring's sample). There 
> isn't Quarts, ibatis or hibernate. There is a controller with a 
> test.jsp only.
>
> I don't understand about memory leak, weark or soft referance but I've 
> see that CachedIntrospectionResults is referenced by  
> CachedIntrospectionResults.classCache and there are 2 instances 
> (org.springframework.context.support.ResourceBundleMessageSource and 
> org.springframework.web.servlet.DispatcherServlet)
>
>
> Where I can call the java.beans.Introspector.flushCaches()?
>
> Please help. After 20 redeploy Tomcat goes in OutOfMemory and ELS craches
>
> At 15.17 15/07/2004 +0200, you wrote:
>
>> If this happens with Spring 1.0.2, it is typically caused by *other* 
>> code that causes a leak. The ClassLoader is then still around, also 
>> showing Spring classes like CachedIntrospectionResults. This is not 
>> Spring's fault: Spring classes just keep hanging around as a side effect.
>>  
>> Try calling "java.beans.Introspector.flushCaches()" on application 
>> shutdown. This is a typical source of such leaks: The JavaBeans 
>> Introspector might still refer to application classes. This is not 
>> caused by Spring: It's rather other libraries that use the 
>> Introspector, for example Quartz.
>>  
>> Juergen
>>  
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von Rod Johnson
>> Gesendet: Do 15.07.2004 14:38
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] CachedIntrospectionResults 
>> classCache leak
>>
>>
>>
>> Claudio
>>
>> What version of Spring is your analysis against?
>>
>> R
>>
>> ----- Original Message -----
>> From: "Claudio D'Angelo" <cla...@ob...>
>> To: <spr...@li...>
>> Sent: Thursday, July 15, 2004 10:26 AM
>> Subject: [Springframework-developer] CachedIntrospectionResults 
>> classCache
>> leak
>>
>>
>> > Hi,
>> > I'm analyzing with OptimizeIt my web application:
>> > when I redeploy the application I note that instances of
>> > CachedIntrospectionResults still in memory and for any redeploy the
>> > instances raise.
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click 
>> <http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click>
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by BEA Weblogic Workshop
>> FREE Java Enterprise J2EE developer tools!
>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>
> Grazie e buon lavoro
> ------------------------------------------------------------------------
> *Claudio D'Angelo
> *Software Consultant
> *ObjectWay S.p.A.
> *Via G.A. Boltraffio 7
> 20159 Milano (MI)
> *http://www.objectway.it <http://www.objectway.it/>
>
> *
> -- 
> La presente comunicazione potrebbe contenere informazioni riservate 
> e/o protette
> da segreto professionale ed e' indirizzata esclusivamente ai 
> destinatari della
> medesima qui indicati. Se avete ricevuto per errore la presente 
> comunicazione,
> siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo 
> di e-mail,
> e a cancellare il presente messaggio dal Vostro sistema. E' 
> strettamente proibito
> e potrebbe essere fonte di violazione di legge qualsiasi uso, 
> comunicazione, copia
> o diffusione dei contenuti di questa comunicazione da parte di chi la 
> abbia
> ricevuta per errore o in violazione degli scopi della presente.
> Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
> pericolosi ed
> e' risultato NON infetto.
>

Re: [Springframework-developer] CachedIntrospectionResults

[Claudio D'A. <cla...@ob...>]

Thank's Guillaume.
I'm studing about the WeakHashMap and I've seen that WeakHashMap build a 
weak reference on the key (it's right??), when the key hasn't any reference 
the entity is removed by map.

Spring use a class type to save the key. When the class object haven't any 
reference? When the Classloader is shutdown?

Can you explain to me (or advise to me if exists an article or tutorial) about?

Thanks,
  Claudio


At 10.05 15/07/2004 -0400, you wrote:
>As Juergen pointed out, if you find a static member hasn't been garbage 
>collected, it just means its ClassLoader cannot be garbage collected yet, 
>the static member is not necessarly at fault there.  For an explanation of 
>the current behavior, see below.
>
>For the solution, you can use a ServletContextListener to call 
>java.beans.Introspector.flushCaches() when the ServletContext is detroy 
>(which causes the ClassLoader to be thrown away).
>
>>                 if (results == null) {
>>                         // can throw BeansException
>>                         results = new CachedIntrospectionResults(clazz);
>>                         boolean cacheSafe = isCacheSafe(clazz);
>>                         if (logger.isDebugEnabled()) {
>>                                 logger.debug("Class [" + clazz.getName() 
>> + "] is " + (!cacheSafe ? "not " : "") + "cache-safe");
>>                         }
>>                         classCache.put(clazz, new WeakReference(results));
>>                 }
>Since Spring 1.0.2, the current code of this method is the following :
>
>         if (results == null) {
>             // can throw BeansException
>             results = new CachedIntrospectionResults(clazz);
>             boolean cacheSafe = isCacheSafe(clazz);
>             if (logger.isDebugEnabled()) {
>                 logger.debug("Class [" + clazz.getName() + "] is " + 
> (!cacheSafe ? "not " : "") + "cache-safe");
>             }
>             if (cacheSafe) {
>                 classCache.put(clazz, results);
>             }
>             else {
>                 classCache.put(clazz, new WeakReference(results));
>             }
>         }
>
>What the isCacheSafe(Class) method does is check if the clazz's 
>ClassLoader is the
>same as CachedIntrospectionResults, or a parent of it.  Because what 
>prevent garbage
>collection of a ClassLoader A is if a class of a ClassLoader B that is not 
>for garbage
>collection has a reference on a class (or instance) of the ClassLoader 
>A.  However, if
>A is a parent of B (or B == A), then A cannot be collected anyway.  Which 
>is why if clazz
>is considered "cacheSafe", no WeakReference is necessary, and in such case 
>it improve
>performance.  For example, if the class introspected is a JDK class, or a 
>Spring class, its
>ClassLoader can never be collected before the CachedIntrospectionResults 
>class.
>
>>I don't understand about memory leak, weark or soft referance but I've 
>>see that CachedIntrospectionResults is referenced 
>>by  CachedIntrospectionResults.classCache and there are 2 instances 
>>(org.springframework.context.support.ResourceBundleMessageSource and 
>>org.springframework.web.servlet.DispatcherServlet)
>I don't know what causes the ClassLoader to be retained, but you cannot 
>easily know what is the cause, just knowning that singletons instances are 
>still in the JVM only proves that the ClassLoader has not been garbage 
>collected.  The problem is that something in a parent (or sibling) 
>ClassLoader still has a reference on a Class of your webapp's 
>ClassLoader.  The trick is to find what is.
>
>Guillaume
>
>Claudio D'Angelo wrote:
>>I've deployed the minimal application (see the spring's sample). There 
>>isn't Quarts, ibatis or hibernate. There is a controller with a test.jsp only.
>>
>>I don't understand about memory leak, weark or soft referance but I've 
>>see that CachedIntrospectionResults is referenced 
>>by  CachedIntrospectionResults.classCache and there are 2 instances 
>>(org.springframework.context.support.ResourceBundleMessageSource and 
>>org.springframework.web.servlet.DispatcherServlet)
>>
>>
>>Where I can call the java.beans.Introspector.flushCaches()?
>>
>>Please help. After 20 redeploy Tomcat goes in OutOfMemory and ELS craches
>>
>>At 15.17 15/07/2004 +0200, you wrote:
>>>If this happens with Spring 1.0.2, it is typically caused by *other* 
>>>code that causes a leak. The ClassLoader is then still around, also 
>>>showing Spring classes like CachedIntrospectionResults. This is not 
>>>Spring's fault: Spring classes just keep hanging around as a side effect.
>>>
>>>Try calling "java.beans.Introspector.flushCaches()" on application 
>>>shutdown. This is a typical source of such leaks: The JavaBeans 
>>>Introspector might still refer to application classes. This is not 
>>>caused by Spring: It's rather other libraries that use the Introspector, 
>>>for example Quartz.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: 
>>><mailto:spr...@li...>spr...@li... 
>>>im Auftrag von Rod Johnson
>>>Gesendet: Do 15.07.2004 14:38
>>>An: 
>>><mailto:spr...@li...>spr...@li...
>>>Betreff: Re: [Springframework-developer] CachedIntrospectionResults 
>>>classCache leak
>>>
>>>
>>>
>>>Claudio
>>>
>>>What version of Spring is your analysis against?
>>>
>>>R
>>>
>>>----- Original Message -----
>>>From: "Claudio D'Angelo" 
>>><mailto:cla...@ob...><cla...@ob...>
>>>To: 
>>><mailto:spr...@li...><spr...@li...>
>>>Sent: Thursday, July 15, 2004 10:26 AM
>>>Subject: [Springframework-developer] CachedIntrospectionResults classCache
>>>leak
>>>
>>>
>>> > Hi,
>>> > I'm analyzing with OptimizeIt my web application:
>>> > when I redeploy the application I note that instances of
>>> > CachedIntrospectionResults still in memory and for any redeploy the
>>> > instances raise.
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>FREE Java Enterprise J2EE developer tools!
>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>><mailto:Spr...@li...>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>FREE Java Enterprise J2EE developer tools!
>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>_______________________________________________
>>>Springframework-developer mailing list
>>><mailto:Spr...@li...>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>Grazie e buon lavoro
>>
>>----------
>>Claudio D'Angelo
>>Software Consultant
>>ObjectWay S.p.A.
>>Via G.A. Boltraffio 7
>>20159 Milano (MI)
>>http://www.objectway.it
>>
>>
>>--
>>La presente comunicazione potrebbe contenere informazioni riservate e/o 
>>protette
>>da segreto professionale ed e' indirizzata esclusivamente ai destinatari 
>>della
>>medesima qui indicati. Se avete ricevuto per errore la presente 
>>comunicazione,
>>siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di 
>>e-mail,
>>e a cancellare il presente messaggio dal Vostro sistema. E' strettamente 
>>proibito
>>e potrebbe essere fonte di violazione di legge qualsiasi uso, 
>>comunicazione, copia
>>o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
>>ricevuta per errore o in violazione degli scopi della presente.
>>Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>>pericolosi ed
>>e' risultato NON infetto.

Grazie e buon lavoro

----------
Claudio D'Angelo
Software Consultant
ObjectWay S.p.A.
Via G.A. Boltraffio 7
20159 Milano (MI)
http://www.objectway.it


-- 
La presente comunicazione potrebbe contenere informazioni riservate e/o
protette
da segreto professionale ed e' indirizzata esclusivamente ai destinatari della
medesima qui indicati. Se avete ricevuto per errore la presente comunicazione,
siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di
e-mail,
e a cancellare il presente messaggio dal Vostro sistema. E' strettamente
proibito
e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione,
copia
o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
ricevuta per errore o in violazione degli scopi della presente.
Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi
ed
e' risultato NON infetto.

Re: [Springframework-developer] CachedIntrospectionResults

[Guillaume P. <gpo...@gl...>]

Claudio,

I'm not completely sure to understand correctly your question, but I 
will try to answer as best as I can.

WeakHashMap is implemented with WeakReference for keys, and strong 
reference for values.  That means if the value has a strong reference on 
the key, then the key cannot be garbage collected until the WeakHashMap 
is ready for collection.  However, if the value has no strong reference 
on its key, then being in the WeakHashMap won't prevent the key and 
value from being garbage collected if it is otherwise ready.  The 
WeakHashMap knows when to remove the key (and the value with it) by 
using the notification provided by the java.lang.ref package.  For more 
information on this, see: 
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html

So the problem here with the CachedIntrospectionResults is that it uses 
BeanInfo and PropertyDescriptor that both have strong reference to the 
class (indirectly by a reference on Methods of the class).  That will be 
solved with JDK 1.5 that uses a combinaison of Weak and Soft Reference 
to the Class and Method objects, but for 1.4.2, there's not really any 
better solution than to flush the Introspector's cache and/or use 
WeakReference on CachedIntrospectionResults. Using WeakReference on the 
CachedIntrospectionResults is safer, but decrease performance, and in 
such case a manual Instrospector.flushFromCaches(Class) must be used, so 
that the Instrospector does not keep a strong reference on the BeanInfo.

When a webapp is hot-redeployed, a new ClassLoader is created to load 
the webapp, and the old one is thrown away, expected to be garbage 
collected.  For the collection to happen, the server must clear any 
strong reference to the ClassLoader or its classes, and also the webapp 
must make sure that any code in parent ClassLoaders (or siblings) clear 
any reference it might have to any of the webapp's class.

Hopefully this answers your question, but if it does not (or if it's not 
clear enough), please give me more details of what information you need.

Regards,
Guillaume


Claudio D'Angelo wrote:

> Thank's Guillaume.
> I'm studing about the WeakHashMap and I've seen that WeakHashMap build 
> a weak reference on the key (it's right??), when the key hasn't any 
> reference the entity is removed by map.
>
> Spring use a class type to save the key. When the class object haven't 
> any reference? When the Classloader is shutdown?
>
> Can you explain to me (or advise to me if exists an article or 
> tutorial) about?
>
> Thanks,
>  Claudio
>
>
> At 10.05 15/07/2004 -0400, you wrote:
>
>> As Juergen pointed out, if you find a static member hasn't been 
>> garbage collected, it just means its ClassLoader cannot be garbage 
>> collected yet, the static member is not necessarly at fault there.  
>> For an explanation of the current behavior, see below.
>>
>> For the solution, you can use a ServletContextListener to call 
>> java.beans.Introspector.flushCaches() when the ServletContext is 
>> detroy (which causes the ClassLoader to be thrown away).
>>
>>>                 if (results == null) {
>>>                         // can throw BeansException
>>>                         results = new CachedIntrospectionResults(clazz);
>>>                         boolean cacheSafe = isCacheSafe(clazz);
>>>                         if (logger.isDebugEnabled()) {
>>>                                 logger.debug("Class [" + 
>>> clazz.getName() + "] is " + (!cacheSafe ? "not " : "") + "cache-safe");
>>>                         }
>>> *                        classCache.put(clazz, new 
>>> WeakReference(results));
>>> *                }
>>
>> Since Spring 1.0.2, the current code of this method is the following :
>>
>>         if (results == null) {
>>             // can throw BeansException
>>             results = new CachedIntrospectionResults(clazz);
>>             boolean cacheSafe = isCacheSafe(clazz);
>>             if (logger.isDebugEnabled()) {
>>                 logger.debug("Class [" + clazz.getName() + "] is " + 
>> (!cacheSafe ? "not " : "") + "cache-safe");
>>             }
>>             if (cacheSafe) {
>>                 classCache.put(clazz, results);
>>             }
>>             else {
>>                 classCache.put(clazz, new WeakReference(results));
>>             }
>>         }
>>
>> What the isCacheSafe(Class) method does is check if the clazz's 
>> ClassLoader is the
>> same as CachedIntrospectionResults, or a parent of it.  Because what 
>> prevent garbage
>> collection of a ClassLoader A is if a class of a ClassLoader B that 
>> is not for garbage
>> collection has a reference on a class (or instance) of the 
>> ClassLoader A.  However, if
>> A is a parent of B (or B == A), then A cannot be collected anyway.  
>> Which is why if clazz
>> is considered "cacheSafe", no WeakReference is necessary, and in such 
>> case it improve
>> performance.  For example, if the class introspected is a JDK class, 
>> or a Spring class, its
>> ClassLoader can never be collected before the 
>> CachedIntrospectionResults class.
>>
>>> I don't understand about memory leak, weark or soft referance but 
>>> I've see that CachedIntrospectionResults is referenced by  
>>> CachedIntrospectionResults.classCache and there are 2 instances 
>>> (org.springframework.context.support.ResourceBundleMessageSource and 
>>> org.springframework.web.servlet.DispatcherServlet)
>>
>> I don't know what causes the ClassLoader to be retained, but you 
>> cannot easily know what is the cause, just knowning that singletons 
>> instances are still in the JVM only proves that the ClassLoader has 
>> not been garbage collected.  The problem is that something in a 
>> parent (or sibling) ClassLoader still has a reference on a Class of 
>> your webapp's ClassLoader.  The trick is to find what is.
>>
>> Guillaume
>>
>> Claudio D'Angelo wrote:
>>
>>> I've deployed the minimal application (see the spring's sample). 
>>> There isn't Quarts, ibatis or hibernate. There is a controller with 
>>> a test.jsp only.
>>>
>>> I don't understand about memory leak, weark or soft referance but 
>>> I've see that CachedIntrospectionResults is referenced by  
>>> CachedIntrospectionResults.classCache and there are 2 instances 
>>> (org.springframework.context.support.ResourceBundleMessageSource and 
>>> org.springframework.web.servlet.DispatcherServlet)
>>>
>>>
>>> Where I can call the java.beans.Introspector.flushCaches()?
>>>
>>> Please help. After 20 redeploy Tomcat goes in OutOfMemory and ELS 
>>> craches
>>>
>>> At 15.17 15/07/2004 +0200, you wrote:
>>>
>>>> If this happens with Spring 1.0.2, it is typically caused by 
>>>> *other* code that causes a leak. The ClassLoader is then still 
>>>> around, also showing Spring classes like 
>>>> CachedIntrospectionResults. This is not Spring's fault: Spring 
>>>> classes just keep hanging around as a side effect.
>>>>  
>>>> Try calling "java.beans.Introspector.flushCaches()" on application 
>>>> shutdown. This is a typical source of such leaks: The JavaBeans 
>>>> Introspector might still refer to application classes. This is not 
>>>> caused by Spring: It's rather other libraries that use the 
>>>> Introspector, for example Quartz.
>>>>  
>>>> Juergen
>>>>  
>>>>
>>>> ________________________________
>>>>
>>>> Von: spr...@li... 
>>>> <mailto:spr...@li...> im 
>>>> Auftrag von Rod Johnson
>>>> Gesendet: Do 15.07.2004 14:38
>>>> An: spr...@li... 
>>>> <mailto:spr...@li...>
>>>> Betreff: Re: [Springframework-developer] CachedIntrospectionResults 
>>>> classCache leak
>>>>
>>>>
>>>>
>>>> Claudio
>>>>
>>>> What version of Spring is your analysis against?
>>>>
>>>> R
>>>>
>>>> ----- Original Message -----
>>>> From: "Claudio D'Angelo" <cla...@ob...> 
>>>> <mailto:cla...@ob...>
>>>> To: <spr...@li...> 
>>>> <mailto:spr...@li...>
>>>> Sent: Thursday, July 15, 2004 10:26 AM
>>>> Subject: [Springframework-developer] CachedIntrospectionResults 
>>>> classCache
>>>> leak
>>>>
>>>>
>>>> > Hi,
>>>> > I'm analyzing with OptimizeIt my web application:
>>>> > when I redeploy the application I note that instances of
>>>> > CachedIntrospectionResults still in memory and for any redeploy the
>>>> > instances raise.
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>> FREE Java Enterprise J2EE developer tools!
>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click 
>>>> <http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click>
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li... 
>>>> <mailto:Spr...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by BEA Weblogic Workshop
>>>> FREE Java Enterprise J2EE developer tools!
>>>> Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li... 
>>>> <mailto:Spr...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>>>
>>>
>>> Grazie e buon lavoro
>>> ------------------------------------------------------------------------
>>> *Claudio D'Angelo
>>> *Software Consultant
>>> *ObjectWay S.p.A.
>>> *Via G.A. Boltraffio 7
>>> 20159 Milano (MI)
>>> *http://www.objectway.it <http://www.objectway.it/>
>>>
>>> *
>>> -- 
>>> La presente comunicazione potrebbe contenere informazioni riservate 
>>> e/o protette
>>> da segreto professionale ed e' indirizzata esclusivamente ai 
>>> destinatari della
>>> medesima qui indicati. Se avete ricevuto per errore la presente 
>>> comunicazione,
>>> siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo 
>>> di e-mail,
>>> e a cancellare il presente messaggio dal Vostro sistema. E' 
>>> strettamente proibito
>>> e potrebbe essere fonte di violazione di legge qualsiasi uso, 
>>> comunicazione, copia
>>> o diffusione dei contenuti di questa comunicazione da parte di chi 
>>> la abbia
>>> ricevuta per errore o in violazione degli scopi della presente.
>>> Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>>> pericolosi ed
>>> e' risultato NON infetto. 
>>
> Grazie e buon lavoro
> ------------------------------------------------------------------------
> *Claudio D'Angelo
> *Software Consultant
> *ObjectWay S.p.A.
> *Via G.A. Boltraffio 7
> 20159 Milano (MI)
> *http://www.objectway.it <http://www.objectway.it/>
>
> *
> -- 
> La presente comunicazione potrebbe contenere informazioni riservate 
> e/o protette
> da segreto professionale ed e' indirizzata esclusivamente ai 
> destinatari della
> medesima qui indicati. Se avete ricevuto per errore la presente 
> comunicazione,
> siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo 
> di e-mail,
> e a cancellare il presente messaggio dal Vostro sistema. E' 
> strettamente proibito
> e potrebbe essere fonte di violazione di legge qualsiasi uso, 
> comunicazione, copia
> o diffusione dei contenuti di questa comunicazione da parte di chi la 
> abbia
> ricevuta per errore o in violazione degli scopi della presente.
> Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
> pericolosi ed
> e' risultato NON infetto.
>

Re: [Springframework-developer] CachedIntrospectionResults

[Claudio D'A. <cla...@ob...>]

I understend.
But how can I save the application server from OutOfMemory or memory leak?
My first problem is that after 20 redeploy the sever must be restarted.

At 11.50 16/07/2004 -0400, you wrote:
>Claudio,
>
>I'm not completely sure to understand correctly your question, but I will 
>try to answer as best as I can.
>
>WeakHashMap is implemented with WeakReference for keys, and strong 
>reference for values.  That means if the value has a strong reference on 
>the key, then the key cannot be garbage collected until the WeakHashMap is 
>ready for collection.  However, if the value has no strong reference on 
>its key, then being in the WeakHashMap won't prevent the key and value 
>from being garbage collected if it is otherwise ready.  The WeakHashMap 
>knows when to remove the key (and the value with it) by using the 
>notification provided by the java.lang.ref package.  For more information 
>on this, see: 
><http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html>http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html
>
>So the problem here with the CachedIntrospectionResults is that it uses 
>BeanInfo and PropertyDescriptor that both have strong reference to the 
>class (indirectly by a reference on Methods of the class).  That will be 
>solved with JDK 1.5 that uses a combinaison of Weak and Soft Reference to 
>the Class and Method objects, but for 1.4.2, there's not really any better 
>solution than to flush the Introspector's cache and/or use WeakReference 
>on CachedIntrospectionResults. Using WeakReference on the 
>CachedIntrospectionResults is safer, but decrease performance, and in such 
>case a manual Instrospector.flushFromCaches(Class) must be used, so that 
>the Instrospector does not keep a strong reference on the BeanInfo.
>
>When a webapp is hot-redeployed, a new ClassLoader is created to load the 
>webapp, and the old one is thrown away, expected to be garbage 
>collected.  For the collection to happen, the server must clear any strong 
>reference to the ClassLoader or its classes, and also the webapp must make 
>sure that any code in parent ClassLoaders (or siblings) clear any 
>reference it might have to any of the webapp's class.
>
>Hopefully this answers your question, but if it does not (or if it's not 
>clear enough), please give me more details of what information you need.
>
>Regards,
>Guillaume
>
>
>Claudio D'Angelo wrote:
>>Thank's Guillaume.
>>I'm studing about the WeakHashMap and I've seen that WeakHashMap build a 
>>weak reference on the key (it's right??), when the key hasn't any 
>>reference the entity is removed by map.
>>
>>Spring use a class type to save the key. When the class object haven't 
>>any reference? When the Classloader is shutdown?
>>
>>Can you explain to me (or advise to me if exists an article or tutorial) 
>>about?
>>
>>Thanks,
>>  Claudio
>>
>>
>>At 10.05 15/07/2004 -0400, you wrote:
>>>As Juergen pointed out, if you find a static member hasn't been garbage 
>>>collected, it just means its ClassLoader cannot be garbage collected 
>>>yet, the static member is not necessarly at fault there.  For an 
>>>explanation of the current behavior, see below.
>>>
>>>For the solution, you can use a ServletContextListener to call 
>>>java.beans.Introspector.flushCaches() when the ServletContext is detroy 
>>>(which causes the ClassLoader to be thrown away).
>>>
>>>>                 if (results == null) {
>>>>                         // can throw BeansException
>>>>                         results = new CachedIntrospectionResults(clazz);
>>>>                         boolean cacheSafe = isCacheSafe(clazz);
>>>>                         if (logger.isDebugEnabled()) {
>>>>                                 logger.debug("Class [" + 
>>>> clazz.getName() + "] is " + (!cacheSafe ? "not " : "") + "cache-safe");
>>>>                         }
>>>>                         classCache.put(clazz, new WeakReference(results));
>>>>                 }
>>>Since Spring 1.0.2, the current code of this method is the following :
>>>
>>>         if (results == null) {
>>>             // can throw BeansException
>>>             results = new CachedIntrospectionResults(clazz);
>>>             boolean cacheSafe = isCacheSafe(clazz);
>>>             if (logger.isDebugEnabled()) {
>>>                 logger.debug("Class [" + clazz.getName() + "] is " + 
>>> (!cacheSafe ? "not " : "") + "cache-safe");
>>>             }
>>>             if (cacheSafe) {
>>>                 classCache.put(clazz, results);
>>>             }
>>>             else {
>>>                 classCache.put(clazz, new WeakReference(results));
>>>             }
>>>         }
>>>
>>>What the isCacheSafe(Class) method does is check if the clazz's 
>>>ClassLoader is the
>>>same as CachedIntrospectionResults, or a parent of it.  Because what 
>>>prevent garbage
>>>collection of a ClassLoader A is if a class of a ClassLoader B that is 
>>>not for garbage
>>>collection has a reference on a class (or instance) of the ClassLoader 
>>>A.  However, if
>>>A is a parent of B (or B == A), then A cannot be collected 
>>>anyway.  Which is why if clazz
>>>is considered "cacheSafe", no WeakReference is necessary, and in such 
>>>case it improve
>>>performance.  For example, if the class introspected is a JDK class, or 
>>>a Spring class, its
>>>ClassLoader can never be collected before the CachedIntrospectionResults 
>>>class.
>>>
>>>>I don't understand about memory leak, weark or soft referance but I've 
>>>>see that CachedIntrospectionResults is referenced 
>>>>by  CachedIntrospectionResults.classCache and there are 2 instances 
>>>>(org.springframework.context.support.ResourceBundleMessageSource and 
>>>>org.springframework.web.servlet.DispatcherServlet)
>>>I don't know what causes the ClassLoader to be retained, but you cannot 
>>>easily know what is the cause, just knowning that singletons instances 
>>>are still in the JVM only proves that the ClassLoader has not been 
>>>garbage collected.  The problem is that something in a parent (or 
>>>sibling) ClassLoader still has a reference on a Class of your webapp's 
>>>ClassLoader.  The trick is to find what is.
>>>
>>>Guillaume
>>>
>>>Claudio D'Angelo wrote:
>>>>I've deployed the minimal application (see the spring's sample). There 
>>>>isn't Quarts, ibatis or hibernate. There is a controller with a test.jsp only.
>>>>
>>>>I don't understand about memory leak, weark or soft referance but I've 
>>>>see that CachedIntrospectionResults is referenced 
>>>>by  CachedIntrospectionResults.classCache and there are 2 instances 
>>>>(org.springframework.context.support.ResourceBundleMessageSource and 
>>>>org.springframework.web.servlet.DispatcherServlet)
>>>>
>>>>
>>>>Where I can call the java.beans.Introspector.flushCaches()?
>>>>
>>>>Please help. After 20 redeploy Tomcat goes in OutOfMemory and ELS craches
>>>>
>>>>At 15.17 15/07/2004 +0200, you wrote:
>>>>>If this happens with Spring 1.0.2, it is typically caused by *other* 
>>>>>code that causes a leak. The ClassLoader is then still around, also 
>>>>>showing Spring classes like CachedIntrospectionResults. This is not 
>>>>>Spring's fault: Spring classes just keep hanging around as a side effect.
>>>>>
>>>>>Try calling "java.beans.Introspector.flushCaches()" on application 
>>>>>shutdown. This is a typical source of such leaks: The JavaBeans 
>>>>>Introspector might still refer to application classes. This is not 
>>>>>caused by Spring: It's rather other libraries that use the 
>>>>>Introspector, for example Quartz.
>>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>________________________________
>>>>>
>>>>>Von: 
>>>>><mailto:spr...@li...>spr...@li... 
>>>>>im Auftrag von Rod Johnson
>>>>>Gesendet: Do 15.07.2004 14:38
>>>>>An: 
>>>>><mailto:spr...@li...>spr...@li...
>>>>>Betreff: Re: [Springframework-developer] CachedIntrospectionResults 
>>>>>classCache leak
>>>>>
>>>>>
>>>>>
>>>>>Claudio
>>>>>
>>>>>What version of Spring is your analysis against?
>>>>>
>>>>>R
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Claudio D'Angelo" 
>>>>><mailto:cla...@ob...><cla...@ob...>
>>>>>To: 
>>>>><mailto:spr...@li...><spr...@li...>
>>>>>Sent: Thursday, July 15, 2004 10:26 AM
>>>>>Subject: [Springframework-developer] CachedIntrospectionResults classCache
>>>>>leak
>>>>>
>>>>>
>>>>> > Hi,
>>>>> > I'm analyzing with OptimizeIt my web application:
>>>>> > when I redeploy the application I note that instances of
>>>>> > CachedIntrospectionResults still in memory and for any redeploy the
>>>>> > instances raise.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>FREE Java Enterprise J2EE developer tools!
>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>>>>>_______________________________________________
>>>>>Springframework-developer mailing list
>>>>><mailto:Spr...@li...>Spr...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by BEA Weblogic Workshop
>>>>>FREE Java Enterprise J2EE developer tools!
>>>>>Get your free copy of BEA WebLogic Workshop 8.1 today.
>>>>>_______________________________________________
>>>>>Springframework-developer mailing list
>>>>><mailto:Spr...@li...>Spr...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>>Grazie e buon lavoro
>>>>
>>>>----------
>>>>Claudio D'Angelo
>>>>Software Consultant
>>>>ObjectWay S.p.A.
>>>>Via G.A. Boltraffio 7
>>>>20159 Milano (MI)
>>>>http://www.objectway.it
>>>>
>>>>
>>>>--
>>>>La presente comunicazione potrebbe contenere informazioni riservate e/o 
>>>>protette
>>>>da segreto professionale ed e' indirizzata esclusivamente ai 
>>>>destinatari della
>>>>medesima qui indicati. Se avete ricevuto per errore la presente 
>>>>comunicazione,
>>>>siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di 
>>>>e-mail,
>>>>e a cancellare il presente messaggio dal Vostro sistema. E' 
>>>>strettamente proibito
>>>>e potrebbe essere fonte di violazione di legge qualsiasi uso, 
>>>>comunicazione, copia
>>>>o diffusione dei contenuti di questa comunicazione da parte di chi la 
>>>>abbia
>>>>ricevuta per errore o in violazione degli scopi della presente.
>>>>Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>>>>pericolosi ed
>>>>e' risultato NON infetto.
>>
>>Grazie e buon lavoro
>>
>>----------
>>Claudio D'Angelo
>>Software Consultant
>>ObjectWay S.p.A.
>>Via G.A. Boltraffio 7
>>20159 Milano (MI)
>>http://www.objectway.it
>>
>>
>>--
>>La presente comunicazione potrebbe contenere informazioni riservate e/o 
>>protette
>>da segreto professionale ed e' indirizzata esclusivamente ai destinatari 
>>della
>>medesima qui indicati. Se avete ricevuto per errore la presente 
>>comunicazione,
>>siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di 
>>e-mail,
>>e a cancellare il presente messaggio dal Vostro sistema. E' strettamente 
>>proibito
>>e potrebbe essere fonte di violazione di legge qualsiasi uso, 
>>comunicazione, copia
>>o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
>>ricevuta per errore o in violazione degli scopi della presente.
>>Il messaggio e' stato analizzato alla ricerca di virus o contenuti 
>>pericolosi ed
>>e' risultato NON infetto.

Grazie e buon lavoro

----------
Claudio D'Angelo
Software Consultant
ObjectWay S.p.A.
Via G.A. Boltraffio 7
20159 Milano (MI)
http://www.objectway.it


-- 
La presente comunicazione potrebbe contenere informazioni riservate e/o
protette
da segreto professionale ed e' indirizzata esclusivamente ai destinatari della
medesima qui indicati. Se avete ricevuto per errore la presente comunicazione,
siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo di
e-mail,
e a cancellare il presente messaggio dal Vostro sistema. E' strettamente
proibito
e potrebbe essere fonte di violazione di legge qualsiasi uso, comunicazione,
copia
o diffusione dei contenuti di questa comunicazione da parte di chi la abbia
ricevuta per errore o in violazione degli scopi della presente.
Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi
ed
e' risultato NON infetto.

Re: [Springframework-developer] CachedIntrospectionResults

[Seth L. <set...@gm...>]

This was discussed a few months ago:

http://thread.gmane.org/gmane.comp.java.springframework.devel/4546

The consensus at that time was it's not a Spring problem, but some of
the libraries used by Spring (eg, Hibernate).  Juergen, and others,
did a lot of profiling.  Apparently, the problems were either fixed or
identified as not a native Spring problem.

<rant>
I think it's sad that due to numerous reasons, we can't keep Tomcat
(or any webapp container) up and running over a day's development. 
Imagine if PHP users had to restart Apache after they change their
.php files > 20 times.

Last I checked, there is an 'E' in J2EE that stands for Enterprise. 
One requirement for Enterprise would be to run 24/7.  That means, to
me, to stay running even after redeployments of new versions of
webapps.

I am so surprised that we as Java developers are so silent on this
issue.  We should demand much more loudly for more robust application
servers and deployments.

I'm not pointing fingers, because I know there are many reasons why we
can't just start Tomcat when the machine starts and leave it running.
</rant>

*phew*

Seth


----- Original Message -----
From: Claudio D'Angelo <cla...@ob...>
Date: Mon, 19 Jul 2004 15:38:30 +0200
Subject: Re: [Springframework-developer] CachedIntrospectionResults
To: spr...@li...


I understend.

But how can I save the application server from OutOfMemory or memory
leak?

My first problem is that after 20 redeploy the sever must be
restarted.

Re: [Springframework-developer] CachedIntrospectionResults

[Guillaume P. <gpo...@gl...>]

If the problem is related to the use of java.beans.Introspector that is =
caching BeanInfo's, then, as I said in a previous email, you need to =
have a javax.servlet.ServletContextListener, that has a call to =
java.beans.Instrospector.flushCaches() in the destroy method.  Spring =
1.1 will offer a built-in listener for such purpose =
(org.springframework.web.util.IntrospectorCleanupListener), but for =
previous version of Spring, you can create your own, it's a fairly =
simple class anyway.  You can see Spring's implementation at: =
http://cvs.sourceforge.net/viewcvs.py/springframework/spring/src/org/spri=
ngframework/web/util/IntrospectorCleanupListener.java?rev=3D1.1&view=3Dma=
rkup.  I would suggest to read that class' javadoc too.  Also, as it was =
mentionned by other people in answer to your mails, note that this =
problem is not Spring related, even if Spring do offers a workaround.

However, if such listener doesn't solve your problem, then I cannot help =
you without being able to reproduce the problem.  I can only tell you =
that if the Introspector is not the cause of the leak, you would need to =
track down what is the cause in order to solve you problem.

Guillaume

  ----- Original Message -----=20
  From: Claudio D'Angelo=20
  To: spr...@li...=20
  Sent: Monday, July 19, 2004 9:38 AM
  Subject: Re: [Springframework-developer] CachedIntrospectionResults


  I understend.
  But how can I save the application server from OutOfMemory or memory =
leak?
  My first problem is that after 20 redeploy the sever must be =
restarted.

  At 11.50 16/07/2004 -0400, you wrote:

    Claudio,

    I'm not completely sure to understand correctly your question, but I =
will try to answer as best as I can.

    WeakHashMap is implemented with WeakReference for keys, and strong =
reference for values.  That means if the value has a strong reference on =
the key, then the key cannot be garbage collected until the WeakHashMap =
is ready for collection.  However, if the value has no strong reference =
on its key, then being in the WeakHashMap won't prevent the key and =
value from being garbage collected if it is otherwise ready.  The =
WeakHashMap knows when to remove the key (and the value with it) by =
using the notification provided by the java.lang.ref package.  For more =
information on this, see: =
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.htm=
l

    So the problem here with the CachedIntrospectionResults is that it =
uses BeanInfo and PropertyDescriptor that both have strong reference to =
the class (indirectly by a reference on Methods of the class).  That =
will be solved with JDK 1.5 that uses a combinaison of Weak and Soft =
Reference to the Class and Method objects, but for 1.4.2, there's not =
really any better solution than to flush the Introspector's cache and/or =
use WeakReference on CachedIntrospectionResults. Using WeakReference on =
the CachedIntrospectionResults is safer, but decrease performance, and =
in such case a manual Instrospector.flushFromCaches(Class) must be used, =
so that the Instrospector does not keep a strong reference on the =
BeanInfo.

    When a webapp is hot-redeployed, a new ClassLoader is created to =
load the webapp, and the old one is thrown away, expected to be garbage =
collected.  For the collection to happen, the server must clear any =
strong reference to the ClassLoader or its classes, and also the webapp =
must make sure that any code in parent ClassLoaders (or siblings) clear =
any reference it might have to any of the webapp's class.

    Hopefully this answers your question, but if it does not (or if it's =
not clear enough), please give me more details of what information you =
need.

    Regards,
    Guillaume


    Claudio D'Angelo wrote:=20

      Thank's Guillaume.
      I'm studing about the WeakHashMap and I've seen that WeakHashMap =
build a weak reference on the key (it's right??), when the key hasn't =
any reference the entity is removed by map.

      Spring use a class type to save the key. When the class object =
haven't any reference? When the Classloader is shutdown?

      Can you explain to me (or advise to me if exists an article or =
tutorial) about?

      Thanks,
       Claudio


      At 10.05 15/07/2004 -0400, you wrote:

        As Juergen pointed out, if you find a static member hasn't been =
garbage collected, it just means its ClassLoader cannot be garbage =
collected yet, the static member is not necessarly at fault there.  For =
an explanation of the current behavior, see below.

        For the solution, you can use a ServletContextListener to call =
java.beans.Introspector.flushCaches() when the ServletContext is detroy =
(which causes the ClassLoader to be thrown away).


                          if (results =3D=3D null) {
                                  // can throw BeansException
                                  results =3D new =
CachedIntrospectionResults(clazz);
                                  boolean cacheSafe =3D =
isCacheSafe(clazz);
                                  if (logger.isDebugEnabled()) {
                                          logger.debug("Class [" + =
clazz.getName() + "] is " + (!cacheSafe ? "not " : "") + "cache-safe");
                                  }
                                  classCache.put(clazz, new =
WeakReference(results));
                          }
        Since Spring 1.0.2, the current code of this method is the =
following :

                if (results =3D=3D null) {
                    // can throw BeansException
                    results =3D new CachedIntrospectionResults(clazz);
                    boolean cacheSafe =3D isCacheSafe(clazz);
                    if (logger.isDebugEnabled()) {
                        logger.debug("Class [" + clazz.getName() + "] is =
" + (!cacheSafe ? "not " : "") + "cache-safe");
                    }
                    if (cacheSafe) {
                        classCache.put(clazz, results);
                    }
                    else {
                        classCache.put(clazz, new =
WeakReference(results));
                    }
                }

        What the isCacheSafe(Class) method does is check if the clazz's =
ClassLoader is the=20
        same as CachedIntrospectionResults, or a parent of it.  Because =
what prevent garbage
        collection of a ClassLoader A is if a class of a ClassLoader B =
that is not for garbage=20
        collection has a reference on a class (or instance) of the =
ClassLoader A.  However, if=20
        A is a parent of B (or B =3D=3D A), then A cannot be collected =
anyway.  Which is why if clazz
        is considered "cacheSafe", no WeakReference is necessary, and in =
such case it improve
        performance.  For example, if the class introspected is a JDK =
class, or a Spring class, its
        ClassLoader can never be collected before the =
CachedIntrospectionResults class.


          I don't understand about memory leak, weark or soft referance =
but I've see that CachedIntrospectionResults is referenced by  =
CachedIntrospectionResults.classCache and there are 2 instances =
(org.springframework.context.support.ResourceBundleMessageSource and =
org.springframework.web.servlet.DispatcherServlet)
        I don't know what causes the ClassLoader to be retained, but you =
cannot easily know what is the cause, just knowning that singletons =
instances are still in the JVM only proves that the ClassLoader has not =
been garbage collected.  The problem is that something in a parent (or =
sibling) ClassLoader still has a reference on a Class of your webapp's =
ClassLoader.  The trick is to find what is.

        Guillaume

        Claudio D'Angelo wrote:=20

          I've deployed the minimal application (see the spring's =
sample). There isn't Quarts, ibatis or hibernate. There is a controller =
with a test.jsp only.

          I don't understand about memory leak, weark or soft referance =
but I've see that CachedIntrospectionResults is referenced by  =
CachedIntrospectionResults.classCache and there are 2 instances =
(org.springframework.context.support.ResourceBundleMessageSource and =
org.springframework.web.servlet.DispatcherServlet)


          Where I can call the java.beans.Introspector.flushCaches()?

          Please help. After 20 redeploy Tomcat goes in OutOfMemory and =
ELS craches

          At 15.17 15/07/2004 +0200, you wrote:

            If this happens with Spring 1.0.2, it is typically caused by =
*other* code that causes a leak. The ClassLoader is then still around, =
also showing Spring classes like CachedIntrospectionResults. This is not =
Spring's fault: Spring classes just keep hanging around as a side =
effect.
            =20
            Try calling "java.beans.Introspector.flushCaches()" on =
application shutdown. This is a typical source of such leaks: The =
JavaBeans Introspector might still refer to application classes. This is =
not caused by Spring: It's rather other libraries that use the =
Introspector, for example Quartz.
            =20
            Juergen
            =20

            ________________________________

            Von: spr...@li... =
im Auftrag von Rod Johnson
            Gesendet: Do 15.07.2004 14:38
            An: spr...@li...
            Betreff: Re: [Springframework-developer] =
CachedIntrospectionResults classCache leak



            Claudio

            What version of Spring is your analysis against?

            R

            ----- Original Message -----
            From: "Claudio D'Angelo" <cla...@ob...>
            To: <spr...@li...>
            Sent: Thursday, July 15, 2004 10:26 AM
            Subject: [Springframework-developer] =
CachedIntrospectionResults classCache
            leak


            > Hi,
            > I'm analyzing with OptimizeIt my web application:
            > when I redeploy the application I note that instances of
            > CachedIntrospectionResults still in memory and for any =
redeploy the
            > instances raise.




            -------------------------------------------------------
            This SF.Net email is sponsored by BEA Weblogic Workshop
            FREE Java Enterprise J2EE developer tools!
            Get your free copy of BEA WebLogic Workshop 8.1 today.
            =
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
            _______________________________________________
            Springframework-developer mailing list
            Spr...@li...
            =
https://lists.sourceforge.net/lists/listinfo/springframework-developer




            -------------------------------------------------------
            This SF.Net email is sponsored by BEA Weblogic Workshop
            FREE Java Enterprise J2EE developer tools!
            Get your free copy of BEA WebLogic Workshop 8.1 today.
            _______________________________________________
            Springframework-developer mailing list
            Spr...@li...
            =
https://lists.sourceforge.net/lists/listinfo/springframework-developer=20

          Grazie e buon lavoro

----------------------------------------------------------------------
          Claudio D'Angelo
          Software Consultant
          ObjectWay S.p.A.
          Via G.A. Boltraffio 7
          20159 Milano (MI)
          http://www.objectway.it


          --=20
          La presente comunicazione potrebbe contenere informazioni =
riservate e/o protette=20
          da segreto professionale ed e' indirizzata esclusivamente ai =
destinatari della=20
          medesima qui indicati. Se avete ricevuto per errore la =
presente comunicazione,=20
          siete invitati a segnalarcelo, rispondendo a questo stesso =
indirizzo di e-mail,=20
          e a cancellare il presente messaggio dal Vostro sistema. E' =
strettamente proibito=20
          e potrebbe essere fonte di violazione di legge qualsiasi uso, =
comunicazione, copia=20
          o diffusione dei contenuti di questa comunicazione da parte di =
chi la abbia=20
          ricevuta per errore o in violazione degli scopi della =
presente.=20
          Il messaggio e' stato analizzato alla ricerca di virus o =
contenuti pericolosi ed=20
          e' risultato NON infetto.=20

      Grazie e buon lavoro

-------------------------------------------------------------------------=
-
      Claudio D'Angelo
      Software Consultant
      ObjectWay S.p.A.
      Via G.A. Boltraffio 7
      20159 Milano (MI)
      http://www.objectway.it


      --=20
      La presente comunicazione potrebbe contenere informazioni =
riservate e/o protette=20
      da segreto professionale ed e' indirizzata esclusivamente ai =
destinatari della=20
      medesima qui indicati. Se avete ricevuto per errore la presente =
comunicazione,=20
      siete invitati a segnalarcelo, rispondendo a questo stesso =
indirizzo di e-mail,=20
      e a cancellare il presente messaggio dal Vostro sistema. E' =
strettamente proibito=20
      e potrebbe essere fonte di violazione di legge qualsiasi uso, =
comunicazione, copia=20
      o diffusione dei contenuti di questa comunicazione da parte di chi =
la abbia=20
      ricevuta per errore o in violazione degli scopi della presente.=20
      Il messaggio e' stato analizzato alla ricerca di virus o contenuti =
pericolosi ed=20
      e' risultato NON infetto.=20
  Grazie e buon lavoro



-------------------------------------------------------------------------=
-----
  Claudio D'Angelo
  Software Consultant
  ObjectWay S.p.A.
  Via G.A. Boltraffio 7
  20159 Milano (MI)
  http://www.objectway.it


  --=20
  La presente comunicazione potrebbe contenere informazioni riservate =
e/o protette=20
  da segreto professionale ed e' indirizzata esclusivamente ai =
destinatari della=20
  medesima qui indicati. Se avete ricevuto per errore la presente =
comunicazione,=20
  siete invitati a segnalarcelo, rispondendo a questo stesso indirizzo =
di e-mail,=20
  e a cancellare il presente messaggio dal Vostro sistema. E' =
strettamente proibito=20
  e potrebbe essere fonte di violazione di legge qualsiasi uso, =
comunicazione, copia=20
  o diffusione dei contenuti di questa comunicazione da parte di chi la =
abbia=20
  ricevuta per errore o in violazione degli scopi della presente.=20
  Il messaggio e' stato analizzato alla ricerca di virus o contenuti =
pericolosi ed=20
  e' risultato NON infetto.