DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33629>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33629 Summary: antiResourceLocking context option creates 'disk space' memory leak and handle leak Product: Tomcat 5 Version: 5.5.7 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Our application uses the Tomcat deployer to do hot redeployment of webapps as part of a production system. As we are constrained to run Tomcat on Windows, we turned the antiResourceLocking flag on (see Tomcat FAQ for Windows), having tried the antiJARLocking flag previously and found it wasn't powerful enough (Tomcat was sometimes failing to completely undeploy webapps). The problem: we discovered that running with antiResourceLocking=true, antiJARLocking=false introduced a huge leak of memory and file handles when redeploying (a linear increase with number of deployments), caused by the Tomcat JVM retaining handles to all of the .jar files in the tomcat\temp\ directory. This also led to a huge 'disk space' leak, with several Gigabytes of old webapps hanging around in the \temp\ directory after a few hundred redeploys. The increase in memory and handles was not present before the antiResourceLocking option was turned on. We are using Struts, and have been able to replicate this behaviour with the elementary struts-blank.war webapp, using Tomcat's own manager app to repeatedly start and stop the app. (Tomcat is running on Windows XP SP2) We tried keeping antiResourceLocking on and setting antiJARLocking=true as well. This meant that all the handles were released and we could delete the remaining jars from the \temp\ folder externally immediately after undeploy - great! But there are still two problems with this solution: 1) The Tomcat Windows FAQ says 'The antiResourceLocking attribute should not be used at the same time as the antiJARLocking attribute.' This suggests something bad happens if you use both - is this really true? If not, the documentation should be changed. Something bad DEFINATELY happens if you DON'T use them together! ;o) 2) Although the file handles all seem to be released, the files still don't get deleted. I suspect this may be because it takes a moment for the handles to be released, and the deletion has been tried and failed before this point. This is a serious problem - after running my stress test app overnight I came in to find that tomcat had fallen over after eating up all 16GB of free disk space! Our solution has been a background 'reaper thread' that tries to delete the temp directories of undeployed apps that have not yet been deleted every few minutes - I think Tomcat should include a fix for this issue when antiResourceLocking is enabled, although I imagine there must be more elegant solutions than this! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]