tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Fix your web application so it can cleanly un-deploy and re-deploy - how?
Date Thu, 07 Nov 2013 21:34:12 GMT
Hash: SHA256


On 11/6/13, 5:50 PM, Dale Ogilvie wrote:
> Chris made the following good suggestion in another thread:
> "Can I make a suggestion? Fix your web application so it can
> cleanly un-deploy and re-deploy and then simply do a hot
> deployment?"
> I've been down this track with our own Spring web apps and found it
> to be quite a deep rabbit hole where a number of 3rd party libs are
> used. We get the issue where the webapp classloader is not GC'ed
> due to classes in the libraries we use not being terminated
> cleanly. Which means we get a big permgen memory leak when we
> redeploy the app. The "occasional tomcat restart" workaround is
> effective, if nasty.

Chuck and (especially) Mark have given good replies. I have some other

> I did what Chris suggested for one of our apps and I think I got
> to 3rd party library problem number FIVE (an oracle jdbc driver
> connection timer) before I gave up in disgust.

As for JDBC drivers, you can force the JDBC driver to be loaded before
the webapp classloader by using the JreMemoryLeakPreventionListener.
It looks like the Tomcat documentation might even have the exact name
of the class you might want to use:

(See the attribute "classesToInitialize").

> As I recall undisposed thread locals were a common theme.

These are taken care-of by ... some component, I think. I can't
remember which one.

> I used various strategies to resolve the prior issues in things as
> simple as logging frameworks, JMS queuing libraries, underlying
> http client code etc. Strategies such as:
> 1. Specifically calling a low level library finalization routine in
> a context listener or Spring lifecycle bean
> 2. Updating the 3rd party library to a later version which fixed
> the leak
> 3. Including Mattias Jiderhamn's active leak prevention library

If you find a bug in a 3rd-party library, you can usually contact the
vendor (or, better yet, contribute a patch to an OSS library) and get
it fixed. Mark's work with Tomcat's memory-leak detection code has
prompted a bunch of fixes in both ASF- and non-ASF-related libraries.

> I would so love it if Tomcat could just throw away the entire
> webapp memory footprint on undeploy... Tomcat 7x memory leak
> protection wasn't good enough for our app a few months ago.

As Mark says, that's not really possible. I mean I suppose
theoretically, one could use JVMTI or whatever and attach to the JVM's
profiling interface, crawl every object in the heap and null-out any
reference to an object whose class was loaded by the
WebappClassLoader, but that would probably cause a few minor disasters
every time you did it (plus it would be hideously inefficient).

> Or failing that, if anyone can share successful strategies for
> "Fixing your web application so it can cleanly un-deploy and
> re-deploy" please do.

If you haven't already, enable the JreMemoryLeakPreventionListener and
make sure you pay attention to it when it complains.

Also, read Mark's slides on tracking-down the problems using a heap

- -chris
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message