Am 07.01.2020 um 09:19 schrieb Dawid Weiss:
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).
Not the only one. Open,
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
Hi,
On Mon, Jan 6, 2020 at 5:39 PM Chris Hegarty wrote:
> // force RST
> clientChannel.setOption(StandardSocketOptions.SO_LINGER, 0);
Just want to point out that when the channel/socket is set in
non-blocking mode, SO_LINGER is either not supported or gives
undefined behavior or throws (
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 r
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 wit
Cross-posting to security-dev as SSL is involved.
--Sean
On 12/29/19 4:01 PM, Dawid Weiss wrote:
Hello,
I am a committer to the Apache Lucene project. We have been looking
into a problem in which SSL connections were handled differently in
tests on different operating systems and narrowed it d
