Problem with half-closure related to connection-reset in Java 11

[Norman Maurer]

> On 29. May 2018, at 16:19, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 29/05/2018 14:52, Norman Maurer wrote:
>> Hi all,
>> 
>> After trying to run our testsuite in Netty [1] with Java11+ea15 I noticed we have one failing test that seems to be related to:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8199329
>> http://hg.openjdk.java.net/jdk/jdk/rev/92cca24c8807
>> 
>> I think the change here is not 100 % correct as it basically disallow draining any remaining bytes from the socket if a write causes a connection reset. This should be completely safe to do. At the moment if a write is causing a connection-reset you basically loose all the pending bytes that are sitting on the socket and are waiting to be read.
>> 
>> This happens because SocketOutputStream.write(…) may call AbstractPlainSocketImpl.setConnectionReset(…). Once this method is called any read(…) call will just throw a SocketException without even attempt to read any remaining data.
>> 
>> This was not the case with earlier Java versions, and I would argue its a bug.
>> 
>> Let me know what you think and please ask if you have any more questions,
> Reading beyond connection reset has always been problematic and never guaranteed to work, esp. on the main stream platforms. I think you are arguing that hitting connection reset when writing shouldn't impact another thread reading. That probably make sense although it's hard to relate to something that depends on such behavior. Can you submit a bug to track this so that we at least track the behavior change?
> 
> -Alan


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).


Bye
Norman