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

[Dmitriy K. <dko...@ru...>]

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
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer