Kees Jan Koster wrote:
Dear Adriano,
As I had having OutOfMemory exceptions (PermGen) when redeploying an
application, I started to verify things using Eclipse Memory Analyzer.
I've discovered some real leaks, for example caused by the Java
Disposer thread being instantiated using the Webapp classloader.
After fix this, when I redeploy the application, Memory Analyzer
shows that there are no non-weak/soft references to the undeployed
classloader. But it (and the classes allocated by it) is never
garbaged collected.
I've tried different VM switches (-XX:+CMS*) and none make the
classloader be collected. Thinking about word "Perm" (permanent) and
some sources, I've done non-web testing and there a custom
classloader *is* garbaged collected.
So what could be the problem when running in Tomcat?
I'm using Tomcat 6.0.18, JDK 1.6.0-10 (Linux and Windows) and Apache
Wicket. I've not put any libraries in <tomcat>/lib, they are all on
the WEB-INF/lib. Wicket uses ThreadGlobals, but I don't think this
may be a problem, because Eclipse Memory Analyzer seems to show
references from them, but it didn't show any references in my case!
Here's some more discussion in that subject.
http://java-monitor.com/forum/showthread.php?t=7 In particular, that
thread suggests you read
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 for
some known permgen leak offenders. Perhaps some of these might give
you more corners to peel at for your application?
After reading this again (I had already read the spring page), I started
done multiple reloads and checks. I don't believe that a Tomcat thread
holds my classloader because Eclipse MAT didn't show them, so in my
tests I didn't even tried to request any page, just reload the app from
the manager application. It may be just how the permgen works. After
some reloads, older classloaders was collected. :-) So this seems not as
real memory leaks.
Thanks,
Adriano
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
