Menu
▾
▴
springframework-developer
|
From: Tim K. <tim...@vi...> - 2004-05-03 19:20:00
|
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.<init > 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 |
|
From: Dmitriy K. <dko...@ru...> - 2004-05-03 19:28:57
|
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.<init > > > 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 |
|
From: Les A. H. <le...@ha...> - 2004-05-04 14:45:35
|
Quoting Dmitriy Kopylenko <dko...@ru...>: > I'm just wondering, would the use of WeakHashMap in > CachedIntrospectionResults help? I'm curious about CachedIntrospectionResults for another reason... What is the minimum JDK supported by Spring? If its JDK 1.4, I would argue that CachedIntrospectionResults is an unnecessary class (and infact incurs additional runtime memory overhead). JDK 1.4 already caches its bean introspection results, including method and property descriptors, and it does so using WeakHashMaps. So when you do a lookup for a bean, it returns the previously cached info (otherwise it does the introspection and then caches it). CachedIntrospectionResults more or less duplicates what the 1.4 java.beans.Introspector already does. If the minimum JDK supported by Spring is < 1.4, I can understand keeping the class, otherwise, wouldn't it be better to deprecate it? If so, it would be an easy fix, since CachedIntrospectionResults is only used in o.s.beans.BeanWrapperImpl in two places to retrieve PropertyDescriptors. Any thoughts? Les |
|
From: Tim K. <tim...@vi...> - 2004-05-04 15:42:54
|
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 > |
|
From: Dmitriy K. <dko...@ru...> - 2004-05-04 14:58:59
|
I believe that the minimum JDK supported by Spring is 1.3 There are some Spring deployments (WebSphere 4 and 5 running 1.3 for instance)... Dmitriy. Les A. Hazlewood wrote: > Quoting Dmitriy Kopylenko <dko...@ru...>: > > >>I'm just wondering, would the use of WeakHashMap in >>CachedIntrospectionResults help? > > > I'm curious about CachedIntrospectionResults for another reason... > > What is the minimum JDK supported by Spring? > > If its JDK 1.4, I would argue that CachedIntrospectionResults is an unnecessary > class (and infact incurs additional runtime memory overhead). > > JDK 1.4 already caches its bean introspection results, including method and > property descriptors, and it does so using WeakHashMaps. So when you do a > lookup for a bean, it returns the previously cached info (otherwise it does the > introspection and then caches it). CachedIntrospectionResults more or less > duplicates what the 1.4 java.beans.Introspector already does. > > If the minimum JDK supported by Spring is < 1.4, I can understand keeping the > class, otherwise, wouldn't it be better to deprecate it? > > If so, it would be an easy fix, since CachedIntrospectionResults is only used in > o.s.beans.BeanWrapperImpl in two places to retrieve PropertyDescriptors. > > Any thoughts? > > Les > > > ------------------------------------------------------- > 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 |
|
From: Dmitriy K. <dko...@ru...> - 2004-05-04 16:02:43
|
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 |
