Windows NIO bug?

[Simone Bordet]

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