2012/11/6 Christopher Schultz <ch...@christopherschultz.net>: > > I was playing around with the manager webapp today and just for grins, > I redeployed my webapp and then hit the "Find Leaks" button to see how > long it would take Tomcat to decide that my webapp reloads cleanly. > > It didn't. That is, my webapp does not appear to cleanly reload. Which > was a surprise to me. > > I waited a few moments and tried again: Find Leaks still says "there's > a leak, confirm with a profiler". So I attached with YourKit, took a > memory snapshot and started looking around: I found 4 > WebappClassLoaders (1 for manager, 1 for my webapp, 1 for a dummy ROOT > webapp I have and finally a started=false WebappClassLoader for the > old pre-reload of my webapp). > > Interestingly, the started=false WebappClassLoader says that it is > Weak/Soft Reachable. That means that tracing GC roots doesn't really work. > > Requesting GC via the manager changes nothing. Requesting GC via the > profiler changes nothing. > > Does anyone have any good ideas for tracking-down what is keeping this > WebappClassLoader in memory? Do I just have to intentionally exhaust > the heap to convince the MM/GC that it should toss-out this WCL? > > Any suggestions would be greatly appreciated. >
1) There exists an -X option that disables explicit GC calls. I hope that you are not using it. 2) I know of a bug in JVM when a certain kind of leak goes undetected. I mean the leak through a shared Exception instance and its native stacktrace. See https://issues.apache.org/bugzilla/show_bug.cgi?id=50460 https://issues.apache.org/bugzilla/show_bug.cgi?id=53936 (Linked from https://wiki.apache.org/tomcat/MemoryLeakProtection) Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
