[ 
https://issues.apache.org/jira/browse/EXEC-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

fagu updated EXEC-101:
----------------------
    Comment: was deleted

(was: I propose a fix in the ticket EXEC-102)

> IOException when a process terminates before all buffered input bytes have 
> been written
> ---------------------------------------------------------------------------------------
>
>                 Key: EXEC-101
>                 URL: https://issues.apache.org/jira/browse/EXEC-101
>             Project: Commons Exec
>          Issue Type: Bug
>    Affects Versions: 1.3
>         Environment: Oracle JDK 1.8.0_72 x64 on MS Windows 10 Pro x64
>            Reporter: Yaniv Kunda
>            Assignee: Siegfried Goeschl
>            Priority: Major
>         Attachments: Test.java
>
>
> I encountered a serious glitch when using commons-exec 1.3 with Java 8 - 
> something that didn't happen with previous Java versions (tested with Java 5 
> and 7).
> In order to feed a process' normal input stream, commons-exec uses 
> Process.getOutputStream() - which is normally a BufferedOutputStream, 
> wrapping a FileOutputStream, pointing to the OS's pseudo-file connected to 
> the process' normal input stream.
> In Java 8, the process might terminate with the BufferedOutputStream still 
> having unwritten bytes in its buffer, while the underlying FileOutputStream 
> gets automatically closed.
> DefaultExecutor always tries to close all of the process' streams, in 
> closeProcessStreams() - but because the process' BufferedOutputStream still 
> has bytes in its buffers (count > 0), it first tries to flush it to the 
> underlying FileOutputStreams, throwing an IOException (Stream closed).
> The following scenario reproduces the problem:
> # Use DefaultExecutor to start a process which does not expect (or read) any 
> bytes from the normal input stream.
> # Feed the process (using PumpStreamHandler) a large amount of bytes.
> # Execute
> The change in behavior between Java 8 and previous versions actually lies 
> within FilterOutputStream, which contains the implementation of close() used 
> by BufferOutputStream - before Java 8, the implementation would ignore 
> (swallow) any exception cause by the call to flush() in close() - in Java 8, 
> the exception propagates.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Reply via email to