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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
