DO NOT REPLY [Bug 33629] New: - antiResourceLocking context option creates 'disk space' memory leak and handle leak

[bu...@apache.org]

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: bjs@apama.com


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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org