Asynchronous channel close in Java NIO

Question

Suppose I have simple nio based java server. For example (simplified code):

while (!self.isInterrupted()) {
  if (selector.select() <= 0) {
    continue;
  }

  Iterator<SelectionKey> iterator = selector.selectedKeys().iterator();
  while (iterator.hasNext()) {
    SelectionKey key = iterator.next();
    iterator.remove();
    SelectableChannel channel = key.channel();

    if (key.isValid() && key.isAcceptable()) {
      SocketChannel client = ((ServerSocketChannel) channel).accept();
      if (client != null) {
        client.configureBlocking(false);
        client.register(selector, SelectionKey.OP_READ);
      }
    } else if (key.isValid() && key.isReadable()) {
      channel.read(buffer);
      channel.close();
    }
  }
}

So, this is simple single threaded non blocking server.

Problem reside in following code.

channel.read(buffer);
channel.close();

When I closing channel in same thread (thread that accept connection and reading data) all works fine. But I got a problem when connection closed in another thread. For example

((SocketChannel) channel).read(buffer);
executor.execute(new Runnable() {
   public void run() {
     channel.close();
   }
});

In this scenario I ended up with socket in state TIME_WAIT on server and ESTABLISHED on client. So connection is not closing gracefully. Any ideas what's wrong? What I missed?

What the host OS? This may be an implementation feature/bug as the package specs assert that these are all thread-safe constructs. — alphazero
Host machine under Mac OS X 10.5.6. Today I'm repeat tests under windows 7 and it's work just fine. Seems like you are right. — Denis Bazhenov
What happens if you close channel.socket() before closing the channel? — Nuoji
For me it's all the same (at least on windows). If I call channel.socket().close(), channel becomes closed (with gracefull client disconnect). — Denis Bazhenov
Behavior is identical in 1.4, 1.5 and 1.6, at least on my Mac, so I suggest following my advice below and do it on the same thread. That strategy also has the virtue of simplifying other features you're likely to want to add to your server. — Nuoji

Vladimir Dyuzhev Vladimir Dyuzhev · Accepted Answer · 2009-06-05T16:53:39

TIME_WAIT means the OS has received a request to close the socket, but waits for possible late communications from the client side. Client apparently didn't get the RST, since it's still thinks it's ESTABLISHED. It's not Java stuff, it's OS. RST is apparently delayed by OS -- for whatever reason.

Why it only happens when you close it in another thread -- who knows? May be OS believes that closes in another thread should wait for original thread exit, or something. As I said, it's OS internal mechanics.

Asynchronous channel close in Java NIO

5 Answers