<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span class=""><div class="">I agree with David, this is an expected difference between the socket</div><div class="">layers on different operating systems. The different behaviours are</div><div class="">acceptable implementations on said operating systems. Unfortunately,</div><div class="">this results in different behaviour of the Java socket (and TCP socket</div><div class="">channel) APIs, when running on different platforms (as you are</div><div class="">observing).</div><div class=""><br class=""></div><div class="">I am not suggesting that you do this, but if the intention is that the</div><div class="">server issues a forceful / abortive close, then ( at least in the</div><div class="">minimal repo case ) one could:</div><div class=""><br class=""></div><div class=""> // force RST</div><div class=""> clientChannel.setOption(StandardSocketOptions.SO_LINGER, 0);</div><div class=""><br class=""></div><div class="">I read over the Lucene issue that you sited; it appears that the</div><div class="">higher-level problem you are encountering is how/when to issue an HTTP</div><div class="">retry request when there is a socket or perceived SSL exception. And how</div><div class="">the SSLSocketImpl handles the difference between the above socket layer</div><div class="">behaviours.</div><div class=""><br class=""></div><div class="">SSLSocket aggregates both the network socket operations and SSL protocol</div><div class="">implementation, which makes it more difficult to discern where the</div><div class="">underlying issue is coming from, than say, if one was to use</div><div class="">SocketChannel along with SSLEngine. However, I would expect that any</div><div class="">SSLException that has a SocketException as its cause could be considered</div><div class="">as a "network problem" - as described by the SocketException message.</div><div class="">The wrapping SSLException in such a case should provide additional</div><div class="">SSL protocol specific information to help with diagnosis, e.g. the</div><div class="">current protocol state.</div><div class=""><br class=""></div><div class="">I'm sure that this is not the answer that you were looking for, but</div><div class="">maybe you can consider it when making a decision on whether this can be</div><div class="">fixed in the HTTP Client that you are using.</div><div class=""><br class=""></div><div class="">-Chris.</div></span><span class=""><br class=""></span><div><blockquote type="cite" class=""><div class="">On 3 Jan 2020, at 13:53, David Lloyd <<a href="mailto:david.lloyd@redhat.com" class="">david.lloyd@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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).</div></div></div></blockquote></div><br class=""></body></html>