Hi Chris, I'll follow up later tonight. Hopefully I'll have less typos then, but don't be surprised if I just go triple-negative instead :)
~Mark -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 21, 2009 3:47 PM To: Tomcat Users List Subject: Re: Headstart on "Resolving OOM-PermGen errors on webapp reload" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark, On 4/21/2009 6:17 PM, mark_desp...@mcafee.com wrote: > None of the issues I've looked into have never been attributed to > Tomcat. You mean "ever" attributed to Tomcat, right? Good. ;) > * A webapp registering an object with another object that outlives > the webapp and forgetting to unregister it webapp shutdown. As a > result, that object cannot be garbage collected, which also prevents > that webapp's classloader from being garbage collected. It's worse than that: even if most of the objects created from classes loaded by that ClassLoader have gone out of scope and can be GC'd, the java.lang.Class, java.lang.Package, and java.lang.reflect.* objects that are created from those loaded classes won't be released until the ClassLoader is released. So if you have a single object that is being held by an object loaded by another ClassLoader, you can have potentially hundreds or thousands of objects left around in memory just wasting space. > * Instantiating a new Thread somehow (e.g. directly via its > constructor, or indirectly via a thread pool, a Timer, or a > ScheduledExecutorService) in response to a request to a webapp. This > is because, by default, the new Thread inherits the parent thread's > context classloader, which in Tomcat (5.5.x) is set to that webapp's > classloader. This is a very good point to consider, because many folks aren't aware of the thread->classloader relationship. If you don't kill your threads, you will keep your whole app's ClassLoader around forever. The 'daemonness' of the thread is not relevant. I'm looking at you, Quartz! > To help pro-actively detect webapp classloader garbage collection > issues, I've leveraged the Insane library (a library I found from > Netbeans while researching the topic) to write a utility that > searches for webapp classloaders that should have been garbage > collected. Using the utility in combination with automated tests has > been definitely helped catch and diagnose issues. Could you post some more info on this? I'm sure a lot of folks would be interested in this kind of thing. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknuTNYACgkQ9CaO5/Lv0PCN6wCgkDKwhzpRB7re4StuClVe1Rt/ 3K0Anj5eXjLiTql97dxbhrNFavPXGIvC =Iuos -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
