|
From: <jue...@we...> - 2004-05-23 20:46:58
|
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!) =20 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). =20 - A classic singleton with a class variable holding the object. I've = reworked GlobalAdvisorAdapterRegistry and SQLErrorCodesFactory to hold = the respective singleton as a WeakReference. =20 - A static cache. I've reworked CachedIntrospectionResults to use a = WeakHashMap with WeakReferences as values. =20 - 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. =20 - 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. =20 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. =20 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. =20 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". =20 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. =20 For this reason, I will delay release 1.0.2 till tomorrow night. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [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=20 >>> have essentially a duplicate group of those objects (same instance=20 >>> count) as the original, and successive reloads will continue to=20 >>> duplicate this. >>> The profiler also shows the final reference to those objects like = this: >>> 100% - 1008 bytes - 63 alloc.=20 >>> = 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=3D3149&alloc_id=3D8166&op=3Dclick >>> _______________________________________________ >>> 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=3D3149&alloc_id=3D8166&op=3Dclick >> _______________________________________________ >> 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=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > 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=3D3149&alloc_id=3D8166&op=3Dclick _______________________________________________ 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_id149&alloc_id=8166&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |