In our webapps running on Tomcat 7 we have seen quite a number of classloader memory leaks. The end result is that after a number of application reloads and redeploys, we run out of permanent generation memory and Tomcat stops responding. We can see the evidence of this sort of issue thanks to the new memory leak reporting in TC6+
Generally we can trace this back to service semantics library code, ActiveMQ, Quartz, etc. I spent a fair bit of time hunting out these sort of issues, squashing some of them by explicitly calling specific finalization routines in each library, on context closure. My question is, why is it that we have to be bothered by this show-stopper memory leak? When the application is unloaded by Tomcat, it should go away completely, regardless of (for example) unstopped threads in library foo. My semi-rant is inspired by the following recent comment by Mladen Turk. "Entire IIS worker process recycling is meant for handling crappy .NET applications with memory and resource leaks." So, why can't Tomcat completely clean up our crappy java apps ;-) when a reload is requested? Thanks Dale
