Menu
▾
▴
RE: [Springframework-developer] Cleanup of context resources on webapp reload
|
From: Alef A. <al...@jt...> - 2004-05-24 08:17:06
|
There's a thread on the tapestry user list as well about this, they seem = to conclude that OC4J has the same issue... http://www.caddr.com/macho/archives/tapestry-users/2004-3/4939.html Also, there was a discussion going on at the forums, I'll update the = people involved there... Alef > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of j=FCrgen h=F6ller [werk3AT] > Sent: Monday, May 24, 2004 9:21 AM > To: spr...@li... > Subject: Re: [Springframework-developer] Cleanup of context resources = on > webapp reload >=20 > FYI, I've tested both Tomcat 5.0.18 and 4.1.27 - same behavior with = both. >=20 > BTW, a couple of related posts from the Resin mailing list: >=20 > http://www.caucho.com/support/resin-interest/0404/0117.html > http://www.caucho.com/support/resin-interest/0111/0164.html > <http://www.caucho.com/support/resin-interest/0111/0164.html> >=20 > Juergen >=20 >=20 > ________________________________ >=20 > Von: spr...@li... im Auftrag = von > j=FCrgen h=F6ller [werk3AT] > Gesendet: Mo 24.05.2004 08:42 > An: spr...@li... > Betreff: Re: [Springframework-developer] Cleanup of context resources = on > webapp reload >=20 >=20 >=20 > I've told JProfiler to explicitly run garbage collection - a number of > times, actually - before I've had a look at the heap. So I'm sure that > those remaining objects were not garbage-collected, and probably would > have stayed around in the VM forever... >=20 > I'm aware that it seems odd, but this issue just seems to affect = specific > static fields: BeanWrapperImpl's defaultEditors did not cause a leak, = but > CachedIntrospectionResults' classCache did. Normal constants or static > logger fields didn't, but "full object" constants like = ClassFilters.TRUE > did. >=20 > CachedIntrospectionResults' classCache uses the Class as key; the = value, a > CachedIntrospectionResult object, also refers to the key Class. > Consequently, I had to use a WeakHashMap *with WeakReferences as = values* > to see proper garbage collection. Note that this static cache contains > instances of its containing class as values. >=20 > I've run all my tests x times to make sure that I could trust my eyes. > I've even undone the WeakReference changes again, and voila, there = were > the leaks again. I'd be happy to learn more about how the garbage > collector works here... All I can state at this point of time is that = the > changes did cause an obvious difference in terms of resource leaks. >=20 > Juergen >=20 >=20 > ________________________________ >=20 > Von: spr...@li... im Auftrag = von > Guillaume Poirier > Gesendet: Mo 24.05.2004 05:17 > An: spr...@li... > Betreff: Re: [Springframework-developer] Cleanup of context resources = on > webapp reload >=20 >=20 >=20 > The "resource leak" caused by a singleton when a webapp's classloader = is > thrown away is only temorary, the unused classes and the classloader = will > be > eventually garbage collected and the resources will be freed. The = only > thing that could prevent that is if there was a something in the = server's > classloader that still had a reference on an object or a class of the > child > classloader. >=20 > Unless there's a bug in Tomcat or in the application code, I really = can't > see how the classes won't be eventually garbage collected when the JVM > needs > memory. And anyway, if there was indeed a leak because > SQLErrorCodesFactory > is a singleton, why wouldn't there be one for each static fields such = as > constants? >=20 > Are you sure that JProfiler does not disable garbage collecting in = order > to > make its profiling? I know that in many of the JVMPI method calls are > done > with garbage collecting off. I suspect the above to be the cause of = the > "resource leak", rather than any singleton that Spring might be using. >=20 > Guillaume >=20 > ----- Original Message ----- > From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> > To: <spr...@li...> > Sent: Sunday, May 23, 2004 4:45 PM > Subject: Re: [Springframework-developer] Cleanup of context resources = on > webapp reload >=20 >=20 > 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 >=20 > ________________________________ >=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 >=20 >=20 >=20 > 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? >=20 > Juergen >=20 >=20 > ________________________________ >=20 > 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 >=20 >=20 >=20 > Well, >=20 > 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... >=20 > Dmitriy >=20 > Tim Kettering wrote: >=20 > > > > 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_id149&alloc_id=8166&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=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=3Dclick > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > = https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Dclick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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=3Dclick > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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 |
