Found different in behavior of SocketInputStream#read in JDK13

[Alan Bateman]

On 01/08/2019 10:47, Enrico Olivelli wrote:
>
> Just to be clear. What is the plan now ? to leave JDK13 as it is 
> currently or to change the behavior ?
>
Just getting back to this one.

I think we've established in this discussion here that the behavior 
change arises when closing a TCP socket with bytes in the receive queue. 
The JDK behavior in this scenario varies by platform and release. It 
also varies depending on whether SO_LINGER is enabled and the linger 
value. Additionally for SocketChannels, it depends on whether the 
channel is registered with a Selector or not.

Here's the behavior of close with unread data with JDK 8, 11, and 13 :

JDK 8
====

java.net.Socket
   Windows: hard close if linger enabled, graceful close if linger disabled
   Linux/macOS: hard close

SocketChannel
   Windows: hard close if linger enabled, graceful close if linger disabled
   Linux/macOS: hard close


JDK 11
====

java.net.Socket
   Windows: hard close if linger enabled, graceful close if linger disabled
   Linux/macOS: hard close

SocketChannel
   All platforms: hard close if linger enabled with a value of 0 or not 
registered with a Selector, graceful close otherwise


JDK 13
====

java.net.Socket
   All platforms: hard close if linger enabled with a value of 0, 
graceful close otherwise

SocketChannel
   All platforms: hard close if linger enabled with a value of 0 or not 
registered with a Selector, graceful close otherwise


As you can see, there is a matrix of scenarios so having the Zookeeper 
test handle both a graceful close and the server resetting the 
connection means it should work in all scenarios.

I discussed briefly the subtle behavior change in JDK 13 with Chris and 
I and I think we've agreed that we shouldn't attempt to change the JDK 
13 behavior (JDK 13 has since got to RC phase and this isn't a 
showstopper). One nice thing about the JDK 13 behavior is that it is 
consistent across platforms so it may be that we should just leave it as 
it and just document this as another behavior change in the JEP.

-Alan.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190809/51e338d1/attachment.html>