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.