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