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

[Colin S. <col...@ex...>]

Just gave CVS Head a go with my main app (was using source about a week 
old, previously). All seems ok for basic container operations, 
transactions, and Hibernate. Unit tests all run fine on the couple of 
machines I build on...


jürgen höller [werk3AT] wrote:

>I've just spent about 10 hours profiling Spring, using the Image Database and Petclinic samples. (BTW, I've used an evaluation version of JProfiler from ej-technologies - nice product!)
> 
>Although I still don't completely understand the garbage collection behavior, I've figured out the following issues. Each of them simply prevents the respective classes from getting garbage collected on destruction of the class loader (e.g. on Tomcat web app shutdown).
> 
>- A classic singleton with a class variable holding the object. I've reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold the respective singleton as a WeakReference.
> 
>- A static cache. I've reworked CachedIntrospectionResults to use a WeakHashMap with WeakReferences as values.
> 
>- A ThreadLocal with a default other than null. I've reworked TransactionSynchronizationManager to use null as default for the resource map, setting a HashMap there on demand, removing the entire HashMap when unbinding the last resource.
> 
>- Constants that define a full object. We have a number of those, for example ClassFilters.TRUE and AdvisedSupport.EMPTY_TARGET_SOURCE. I've tried for quite a while, but I haven't been able to figure out a way to define such constants such that they will be garbage collected.
> 
>The latter programming style is not uncommon, so I really don't understand why it causes trouble with garbage collection. Hibernate uses a similar style for its FlushMode, for example.
> 
>In general, other frameworks like CGLIB, Hibernate, Velocity have huge resource leaks on web app shutdown, while just the constants issue remains with Spring now. As long as those huge third-party leaks are not addressed, I'm not worried at all by the single remaining Spring issue.
> 
>As I initially said, we shouldn't exaggerate the problem, as it basically just affects hot reloading of web apps - mainly a development feature anyway. We need to make that clear to users too, to avoid comments a la "Spring is not usable for real apps because it leaks on hot redeployment".
> 
>Please, everybody, give the current CVS head a sanity check tomorrow. There shouldn't be any issues: the test suite passes, the sample apps run properly. Still, I'd feel more comfortable if we make sure that no subtle side effects have been introduced.
> 
>For this reason, I will delay release 1.0.2 till tomorrow night.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Sa 22.05.2004 15:52
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
>
>
>
>So basically, all static caches cause resource leaks when restarting a Tomcat web app? I wonder why this happens... The class loader should completely dissolve all classes that it has loaded in its lifetime, including static caches. Or have I misunderstood something here? Anyone having in-detail experience with handling such a scenario?
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Dmitriy Kopylenko
>Gesendet: Di 04.05.2004 18:02
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Cleanup of context resources on webapp reload
>
>
>
>Well,
>
>for instance SQLErrorCodesFactory is a singleton(GoF, not Spring) which caches SQLErrorCodes internally in the Map with strong references. Again, I don't know if trying
>to use WeakHashMap there would do the trick...
>
>Dmitriy
>
>Tim Kettering wrote:
>
>  
>
>>I looked at it some more this morning, and basically what I did was
>>start up tomcat w/ the webapp in the profiler, then after it was done
>>starting up I used tomcat's manager to stop the context.  This should
>>destroy all resources related to the context.   Here is a list of
>>spring related stuff that still were in memory after the context was
>>closed.  Other stuff was cleaned up just fine.
>>
>>org.springframework.beans.CachedIntrospectionResults
>>org.springframework.jdbc.support.SQLCodes
>>org.springframework.core.Constants
>>org.springframework.aop.framework.AdvisedSupport$1
>>org.springframework.aop.framework.adapter.BeforeAdviceAdapter
>>org.springframework.aop.framework.adapter.AfterReturningAdviceAdapter
>>org.springframework.jdbc.support.SQLErrorCodesFactory
>>org.springframework.transaction.support.TransactionSynchronizationManage
>>r$1
>>org.springframework.transaction.interceptor.RollbackRuleAttribute
>>org.springframework.aop.framework.adapter.ThrosAdviceAdapter
>>org.springframework.aop.Pointcut$1
>>org.springframework.aop.framework.adapter.GlobalAdvisorAdapterRegistry
>>
>>On May 3, 2004, at 3:28 PM, Dmitriy Kopylenko wrote:
>>
>>    
>>
>>>I'm just wondering, would the use of WeakHashMap in
>>>CachedIntrospectionResults help?
>>>
>>>Dmitriy.
>>>
>>>Tim Kettering wrote:
>>>
>>>      
>>>
>>>>I posted this to the users list last week and did not receive any
>>>>reply  on it, so I'm posting it again here on the developer list, in
>>>>hopes i  could get an reply from someone here.   I'm trying to
>>>>determine if its  something I should be doing myself, or if hte
>>>>spring context should be  cleaning up those resources by itself on
>>>>the .close() call.  Further  profiling shows that there are
>>>>duplicate  instances of SQLError and  hibernate proxy classes hanging
>>>>around  afterwards too.  Other objects  do get cleaned up properly.
>>>>--------
>>>>Hi everyone,
>>>>We're (meaning me) looking into some resource leaks that are
>>>>occuring   when our webapp context gets reloaded.  I found that
>>>>context.close()   needs to be called on the destroy() method of
>>>>plugin we're using,  and  it works for a good majority of the objects
>>>>we were seeing  leaked, but  there are some objects that I'm unable
>>>>to make go away.  Object in  question is the:
>>>>org.springframework.beans.CachedIntrospectionResults
>>>>Whenever I reload the context - the profiler I'm using shows that I 
>>>>have essentially a duplicate group of those objects (same instance 
>>>>count) as the original, and successive reloads will continue to 
>>>>duplicate this.
>>>>The profiler also shows the final reference to those objects like  this:
>>>>100% - 1008 bytes - 63 alloc. 
>>>>org.springframework.context.support.ClassPathXmlApplicationContext.<in
>>>>it >
>>>>So basically I guess what I'm asking is for ideas or suggestions on
>>>>how  I could get those to clean up.  This bean doesnt show up in the
>>>>Spring  javadocs.  And looking in CVS says its a package level bean,
>>>>not for  application use, so I'm thinking that closing the context
>>>>should (in  theory) clean this up?   Thanks in advance.
>>>>-tim
>>>>-------------------------------------------------------
>>>>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=3149&alloc_id=8166&op=click
>>>>        
>>>>