https://bz.apache.org/bugzilla/show_bug.cgi?id=58900
Bug ID: 58900
Summary: Memory leak due to infinite redeploy loop
Product: Tomcat 8
Version: trunk
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: lauri.h.lehti...@gmail.com
Created attachment 33471
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33471&action=edit
JConsole screen while observing this behavior
## Reproduction steps ##
To reproduce this issue:
1. Add undeployOldVersions="true" to the otherwise default Host configuration
in server.xml
2. Do a parallel deployment of two versions of the same war by creating a
symlink to the actual war file(s):
$ ln -s /path/to/app.war /path/to/webapps/app#001.war
$ ln -s /path/to/app.war /path/to/webapps/app#002.war
Shortly after startup, Tomcat undeploys app##001 (the "old version"). However,
the war file is not deleted, and ends up getting redeployed. This happens over
and over again, until at some point the number of loaded classes grows too big
and OutOfMemoryError happens.
## Root cause ##
What's preventing the symlinked war from getting deleted is this line in
org.apache.catalina.startup.HostConfig#deleteRedeployResources:
current = current.getCanonicalFile();
The canonical file is war file the symlink is pointing to, and the
isDeletableResource method determines that it should not be deleted.
## Context ##
This issue has been plaguing me on a CentOS/6 server running 7.0.55, but
appears to affect 8.x and 9.x as well. I reproduced it locally on OSX. My
Struts2/Spring/Hibernate application died within ~10 minutes with -Xmx256m.
Screenshot from jconsole attached, undeploy/redeploy cycle can be seen clearly
in the CPU usage and number of classes loaded.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
