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
Summary: org.apache.tools.ant.taskdefs.Execute
Product: Ant
Version: 1.7Alpha (nightly)
Platform: Other
OS/Version: All
Status: NEW
Severity: Minor
Priority: Other
Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: gus_goose@canada.com
Execute task creates a java.lang.Process object when launching some commands.
The STDIN, STDOUT, and STDERR for the process are captured, and given to the
ExecuteStreamHandler. These are represented by an OutputStream, and two
InputStreams.
In the most common case (PumpedStreamHandler), there is no explicit close()
called on any of these streams. Thus, until the GC runs, these streams all hold
OS resources (in particular File Descriptors).
In perusing the code, I believe that in every instance that the
PumpedStreamHandler is use, it is safe to close() all the streams in the stop()
method. Further, although I am less certain, I believe it is safe, and probably
more desirable to close() each stream after calling the stop() method of the
ExecuteStreamHandler in the execute() method in Execute.
I encountered this problem in a non-standard use of ant, where I have multiple
tasks all "executing" regularly, and repeatedly. Because GC was slow (and at
times I switched it off in the VM), I routinely ran out of file-descriptors
(ulimit -H -n == 1024).
My current workaround solution is to implement my own Stream Handler
(duplicating much of PumpedStreamHandler), which explicitly close()'s the
Streams in the stop() method.
gus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
|