Reading from a closed socket: different behavior between Linux and other operating systems

[Dawid Weiss]

Thank you for your feedback.

I can understand how this behavior can be considered
platform-dependent but it's still a bit surprising that it shows
consistent behavior on everything except Linux... (we originally
thought it's Windows to be blamed here).

For the SSL layer I implemented a workaround Chris suggested.

Dawid

On Mon, Jan 6, 2020 at 5:38 PM Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
> I agree with David, this is an expected difference between the socket
> layers on different operating systems. The different behaviours are
> acceptable implementations on said operating systems. Unfortunately,
> this results in different behaviour of the Java socket (and TCP socket
> channel) APIs, when running on different platforms (as you are
> observing).
>
> I am not suggesting that you do this, but if the intention is that the
> server issues a forceful / abortive close, then ( at least in the
> minimal repo case ) one could:
>
>     // force RST
>     clientChannel.setOption(StandardSocketOptions.SO_LINGER, 0);
>
> I read over the Lucene issue that you sited; it appears that the
> higher-level problem you are encountering is how/when to issue an HTTP
> retry request when there is a socket or perceived SSL exception. And how
> the SSLSocketImpl handles the difference between the above socket layer
> behaviours.
>
> SSLSocket aggregates both the network socket operations and SSL protocol
> implementation, which makes it more difficult to discern where the
> underlying issue is coming from, than say, if one was to use
> SocketChannel along with SSLEngine. However, I would expect that any
> SSLException that has a SocketException as its cause could be considered
> as a "network problem" - as described by the SocketException message.
> The wrapping SSLException in such a case should provide additional
> SSL protocol specific information to help with diagnosis, e.g. the
> current protocol state.
>
> I'm sure that this is not the answer that you were looking for, but
> maybe you can consider it when making a decision on whether this can be
> fixed in the HTTP Client that you are using.
>
> -Chris.
>
> On 3 Jan 2020, at 13:53, David Lloyd <david.lloyd at redhat.com> wrote:
>
> This is, AFAICT, expected based on the differences between the socket layers of the various operating systems involved and their handling of closed sockets.  If you write a similar test program in C using OS specific APIs, I believe you will see similar results.  I don't think this is a problem with the JDK, nor is it likely to be something that can be fixed in the JDK (since the error reported by the OS is, as far as I know, unlikely to be universally sufficient to extrapolate the exact cause of failure).
>
>