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

[Norman Maurer]

> On 1. Jun 2018, at 14:13, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 01/06/2018 10:21, Florian Weimer wrote:
>> On 05/29/2018 04:26 PM, 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.
>> 
>> Are there implementations where the kernel does *not* zap the read buffer when it receives an RST segment?  (Except perhaps Solaris, as mentioned further down the thread.)
> I can't say for sure whether the kernels actually drop the socket buffer or not. For the scenario, the connection reset is reported when writing and on both Linux and macOS you can read the previously received bytes in the socket buffer. Solaris behavior is a bit different due to the way that it reports network issues. Windows does not allow reading the bytes, it errors immediately. It's surprising to hear about a test that depend on such behavior but these are the types of things that come up when changing things in this area.
> 
> -Alan


All I was saying when I reported this issue was that I think there is a behaviour change and we should preserve the old behaviour and just delegate to the OS, which will report an error anyway at some point. IMHO the wrapper around bsd sockets should be as “small” as possible. 

Maybe you are right and the test in question is not something that makes sense in general but we had users in the past that complained when we closed the reading side without draining the socket when an error on the writing side happened. This was when we did some changes to not do so in Netty (by ourselves) and added the test. 

Just to give you a bit of background, hope it helps.

Norman