tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Mark_Desp...@McAfee.com>
Subject RE: Headstart on "Resolving OOM-PermGen errors on webapp reload"
Date Tue, 21 Apr 2009 23:01:04 GMT
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:chris@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_Despain@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Mime
View raw message