-
Bug
-
Resolution: Fixed
-
P4
-
11
-
b14
-
Verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8203545 | 11.0.1 | Alan Bateman | P4 | Resolved | Fixed | team |
This issue concerns closing a SocketChannel that has the SO_LINGER socket option enabled and the channel is registered with a Selector.
SO_LINGER is only specified for sockets configured in blocking mode but there are cases where libraries (or tests) may be enabling SO_LINGER on non-blocking sockets to a value of zero so that they can generate a RST to reset the connection. The behavior for the case that the channel is registered with a Selector has changed in JDK 11 (as part ofJDK-8198562). In JDK 11, the peer will read EOF whereas in JDK 10 and older, the connection will be reset.
More discussion on this issue in this thread:
http://mail.openjdk.java.net/pipermail/nio-dev/2018-May/005101.html
SO_LINGER is only specified for sockets configured in blocking mode but there are cases where libraries (or tests) may be enabling SO_LINGER on non-blocking sockets to a value of zero so that they can generate a RST to reset the connection. The behavior for the case that the channel is registered with a Selector has changed in JDK 11 (as part of
More discussion on this issue in this thread:
http://mail.openjdk.java.net/pipermail/nio-dev/2018-May/005101.html
- backported by
-
JDK-8203545 (so) Closing a socket channel registered with Selector and with SO_LINGER set to 0 does not reset connection
-
- Resolved
-
- relates to
-
JDK-8198562 (ch) Separate blocking and non-blocking code paths (part 1)
-
- Resolved
-