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=28565>. 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=28565 org.apache.tools.ant.taskdefs.Execute ------- Additional Comments From [EMAIL PROTECTED] 2004-05-19 17:59 ------- We found the same problem and developed the exact same fix (having just checked the CVS, it really is). I was comnig in today to submit a bug with the patch, but lo and behold, I am too late. :D I can add that this particular bug will affect Tomcat users who performance tune their JVMs. This is due to the way Tomcat compiles JSPs, actually using Ant and (almost always, due to other problems) forking when compiling - hence the use of Execute. The underlying problem (of not closing the streams of your Process object) is normally concealed, because Java's Process object closes these streams for you in its finalize() method, and the typical garbage collector configuration is subjectively what I would call "aggressive." Processes often don't survive long, and nobody remembers to close the streams on them, but it hardly comes up. Even Sun has omitted the requirement to close the Process's streams in the API documentation for Runtime.exec() and Process, I think because normally, "the GC will do it for you." This runs counter to Sun's own (correct) policy: "...an example is relying on finalization to close file descriptors, which makes an external resource (descriptors) dependent on GC promptness. Relying on GC to manage resources other than memory is almost always a bad idea." (http://java.sun.com/docs/hotspot/gc/) Power users with big machines, big heaps, and unusual settings, especially using things like the concurrent mark-sweep collector (http://java.sun.com/developer/technicalArticles/Programming/turbo/) will find their objects tend to escape into the old generation and linger much longer. Thus, "big" Tomcat installs where JSPs may be added and changed will find themselves chewing up file descriptors (i.e. dangling PIPEs) and going down when they hit OS limits... very unpleasant. The change discussed here does fix the problem. :) Tomcat users impatient for results may substitute a patched ant.jar in their Tomcat install. We patched ant 1.5.4 with this fix and substituted it in Tomcat 4.1.24 without trouble. I can't vouch for trying the same with newer Ant or Tomcat versions, but it will probably work. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
