| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8017391 | 6u65 | Poonam Bajaj Parhar | P3 | Closed | Fixed | b01 |
| JDK-8006352 | 6u60 | Robert Mckenna | P3 | Closed | Fixed | b01 |
| JDK-8005461 | 6u35 | Poonam Bajaj Parhar | P3 | Closed | Fixed | b52 |
It is well-known that a program that calls Process.waitFor
without closing or draining the process output is subject
to deadlock if the process writes more data to its stdout or stderr
than fits into the OS pipe buffer which holds this data.
On Solaris or Linux, there is no control over the size of the
pipe buffer, and is, respectively 13k (!) and 4k.
On Windows, the application (JDK) has control over the size of
the buffer when the subprocess is created, and currently a size of 512
is hard-coded. We should probably raise that to either the Solaris or Linux
limit, both for process I/O throughput and for deadlock avoidance.
without closing or draining the process output is subject
to deadlock if the process writes more data to its stdout or stderr
than fits into the OS pipe buffer which holds this data.
On Solaris or Linux, there is no control over the size of the
pipe buffer, and is, respectively 13k (!) and 4k.
On Windows, the application (JDK) has control over the size of
the buffer when the subprocess is created, and currently a size of 512
is hard-coded. We should probably raise that to either the Solaris or Linux
limit, both for process I/O throughput and for deadlock avoidance.
- backported by
-
JDK-8005461 (process) Raise Windows pipe buffer size (win)
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
JDK-6462165 (process) Preach Process file handle hygiene
-
- Open
-
-
-
- Resolved
-