On 25/11/2025 04:14, Harshit Sharma wrote:
What Chuck said, Plus...
<snip/>
Questions for the Community
1.
Is our symlink-based deployment approach with
autoDeploy="true"causing classloader leaks??
No.
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.
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.
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
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
