DO NOT REPLY [Bug 28565] - org.apache.tools.ant.taskdefs.Execute

[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=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 obsidian@panix.com  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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org