Windows NIO bug?

David Lloyd david.lloyd at
Fri Jul 6 16:41:38 UTC 2018

Maybe try shutdownWrites/shutdownReads before you close?
On Fri, Jul 6, 2018 at 11:13 AM Simone Bordet <simone.bordet at> wrote:
> Hi,
> we're hitting a strange behavior that I would like opinion on from this group.
> A client opens a TCP connection to the server and sends a HTTP request
> with a very large body.
> The server accepts the connection, sets interestOps=OP_READ; the
> selector wakes up, sets interestOps=0 and (another thread) goes back
> to select(); the server reads the HTTP request headers only, sends the
> HTTP response _without_ reading the request body, then closes the
> connection via SocketChannel.close().
> After closing the connection there are 2 cases:
> A) the selector is not woken up again
> B) the selector is woken up
> In case A) we see that the client continues to write the request
> content, the server continues to send back TCP ACKs until the TCP
> connection is congested and the client registers for OP_WRITE.
> Unfortunately the server cannot drain the buffers (its connection is
> gone) and so the client stalls.
> In case B) we see that the client continues to write the request
> content, and after a few writes the server responds with a TCP RST.
> Case B) is what always happens on Linux no matter if the selector is
> woken up or not, and I think it's the correct behavior.
> I can easily turn case A) into case B) by adding a bit of code that
> wakes up the selector (just selector.wakeup() is enough).
> It is as if after SocketChannel.close(), in case A), the selector does
> not tell the TCP stack that the socket is gone, so the TCP stack
> continues to ACK even if the SocketChannel is closed and should be
> even "gone" from the OS as well.
> Has anyone seen this?
> Ideas?
> Thanks!
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz


More information about the nio-dev mailing list