Mark,
A few extra inline comments/...
On 11/25/25 3:01 AM, Mark Thomas wrote:
On 25/11/2025 04:14, Harshit Sharma wrote:
2.
What is the recommended deployment strategy for production
environments to avoid memory leaks when updating WAR files??
Don't deploy applications with memory leaks. This is an application
problem, not a Tomcat problem.
Please note that the above comment about "applications with memory
leaks" was intended to treat "not shutting-down cleanly" as an
application leak. If you can run the application (without restarts) for
10 years without leaking memory, that's great. But if you reload the
application and now you have 2x the number of classes loaded permanently
into the JVM's memory space, this should be considered an "application
with a memory leak".
The link at the very bottom of Mark's reply is a presentation showing
how to find memory leaks such as this. It's 29 pages are deceptively
simple, but it's a deep well. To debug these kinds of issues usually
requires the use of tools like debuggers and memory profilers. Become
familiar with their use and you will be able to find and fix these kinds
of leaks.
3.
Are there known issues with Tomcat 7.0.41 related to classloader
leaks during redeployment??
Not that match your description of a leak every reload (there are a
couple where you might see a leak on the first but not subsequent reloads).
There have been multiple improvements to Tomcat's
JreMemoryLeakPreventionListener since 7.0.41 which helps prevent memory
leaks due to the application's use of various parts of the JRE.
4.
What monitoring or preventive measures can we implement to detect
and mitigate this issue before it causes production outages??
Update to a supported version of Tomcat. The latest 9.0.x release will
be the minimum work since it still supports Java EE. Be sure to read the
migration guides:
https://tomcat.apache.org/migration.html
There is at least one commercial vendor that offers support for Tomcat 7
but even then the supported version is based on 7.0.109 so you'd have a
significant update to do anyway. I doubt updating to 9.0.x would be much
more effort.
+1
We suspect the combination of symlinked WAR files, autoDeploy="true",
and no-restart deployments is preventing proper cleanup of old
classloaders, but we'd like to understand the root cause and implement
a robust solution.
Those suspicions are very likely wrong.
Any insights, best practices, or references to similar issues would be
greatly appreciated.
https://tomcat.apache.org/presentations/2010-08-05-javaone-Memory-
Leaks-60mins.pdf
Please definitely read this. But maybe, first, take some time to see if
your application runs under Tomcat 9. It probably will.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
