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