On 29/05/2018 15:26, Norman Maurer wrote:
:
Yes thats what I am saying… I think if a write fails due a connection-reset a
read should still be possible until we are told by the OS that we also hit an
error here. Honestly I think this scenario can happen quite often in reality
where some software writes while draining data from the socket in chunks. With
Java 11 this may lead to the situation where the user may never see the data
even when its waiting on the socket to be read which I think is weird. What
kind of problems this may cause in different programs is hard to know, but its
definitely something that surprised me. Even more after I started to debug and
could see the packets via tcpdump etc.
Also as a side-note when using SocketChannel this works perfectly fine, as
before. I will open a bug with all the informations in this email as requested.
I just wanted to make sure first that my observations are correct and wanted to
provide as much details as possible ( + making a strong argument to why I think
this is a regression).
I see you've created an issue to the bugs.sun.com system - thanks! I'll
move that to the JDK project so that it's accessible via
bugs.openjdk.java.net.
You are right that there is subtle behavior change, something that
wasn't really intended. The code to manage reading beyond connection
resets has always been problematic and only ever worked on Solaris. The
SocketChannel implementation has never attempt to do this, it just
reflects the platform behavior when reading after a reset.
-Alan.
