tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Fix your web application so it can cleanly un-deploy and re-deploy - how?
Date Thu, 07 Nov 2013 09:16:28 GMT
On 06/11/2013 22:50, 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.
> 
> 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 I recall undisposed
> thread locals were a common theme. 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
> 
> I would so love it if Tomcat could just throw away the entire webapp
> memory footprint on undeploy...

Dale,

Me too. Unfortunately, if references to the web app class loader are
held outside of the web app then this just isn't possible.

> Tomcat 7x memory leak protection
> wasn't good enough for our app a few months ago.

That protection is never going to be the 100% solution for every
application. What we try and do is cover the common causes and provide
enough debug information to point to the root causes of as many of the
other issues as we can. If you are able to share more details of the
leaks you found and how you fixed them there may be something that we
can do to improve the built-in protection.

> 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.

It sounds as if you are heading in the right direction. It isn't an easy
task. One of the goals of the leak prevention listener was education.
The more folks that are aware of the issues then, hopefully, the less
prevalent they will be come. The more folks like you educate your
internal development teams and raise bugs with the third-party libraries
then the better things should get.

As an aside, I suspect that the Tomcat developers and most library
developers have a very different view on the correct use of thread
locals. Fortunately, that is one of those issues we can work-around
(albeit at the expense of renewing the thread pool).

In short, if there is something the Tomcat developers can do to help
then we would love to do so - just let us know.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message