> On 1. Jun 2018, at 14:13, Alan Bateman <alan.bate...@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
