-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dale,
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 thoughts. > 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: http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#JRE_Memory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPreventionListener (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 profiler: http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSfAdUAAoJEBzwKT+lPKRYhBcP/RN2eL2qmxdUATpTfQxbs8Ec PLG59WyQcUBJiKdhmenviTXf6EIcrBCAWmVXlw3+l52y6HvbnfuOl3LlX4grdKUO EWpwg5RJ0dtkgCBpXHBHBdqM2pJ5zcRgGhFB2bgSUT8qo8uB1F8tjbtHAfRsupqc 2RSZXpvAlVNoxQFAt8zBLLYHVzoOTM0s30iE8gAo+xWPReUSQ2TIFe6I1tZYp2on JsSAaiYmRpVgd2x/0Baw0xqIOVHmJr5zaoDKiePivTLKZAHPHDSeDWSJjHWpyan/ l6g+Q/cMwzP7SraaKVVnz0QshEMujYK/HkesI9Kmux99qGjR0c8aWTPnrxm3RcHd hI2PCPNe7mAZNVN9nfEnHylloPCWdtlmyHMmLrXBYeUGbtBxZnehWXGgUSiSqh6U 7/fwLPNpUUssNmt7Y95+5E8qSj+9M22mPK58oGb5+D8Ih0rohrpvWeiuF8AIa6mc v+PF0elb6ximmxvuf9aR1wrjsTCIV1tsqlJWkEgR9aK+DYEeZ5a7IyDxP8kB15zE pydGSk3IRx6pQqWefMeU+r+74KQMPLC4heRHOaFHYtNtQCGOds075BLjajBPpMXY vhPxvRlg2SXbRw4Flk3nFaVYyQbddun6bYwQKlHXcBi8qjqILHR+rCxV6aDVqW99 mjjBFDjhOP2t1QDTTRg0 =vize -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
