-
Sub-task
-
Resolution: Delivered
-
P4
-
11
-
Verified
The implementations of `SocketChannel`, `ServerSocketChannel`, `DatagramChannel`, `Pipe.SourceChannel` and `Pipe.SinkChannel` have been refactored in JDK 11 to separate the code paths for blocking and non-blocking I/O. This improves performance and also improves reliability for cases where a channel is asynchronously closed or threads doing I/O operations are interrupted. The refactoring results the following behavioral changes:
1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors.
2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel.
3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed.
1. Closing a connected `SocketChannel` that is registered with a `Selector` will now consistently delay closing the underlying connection until the closed channel is flushed from all selectors that it is registered with. Similarly, closing a `ServerSocketChannel` that is registered with `Selector` will now consistently delay closing the underlying listener socket until it is flushed from all selectors that it is registered with. The behavior varied by platform in previous releases. Developers using tools such as `netstat` to monitor network connection should be aware of this change, particularly with libraries or applications that do not perform selection operations in a timely manner to flush closed channels from selectors.
2. Invoking an I/O operation on a selectable channel configured non-blocking and with the interrupt status set no longer closes the channel.
3. Invoking `configureBlocking(false)` on a selectable channel will now block until outstanding blocking I/O operations have completed. The specification has always allowed this but the implementation in the JDK didn't historically wait until blocking I/O operations in progress completed.