NIO Selector object can't detect OP_ACCEPT event in time.

Question

We developed a server with Java NIO. we use a special thread to accept new SocketChannel object, read data, write data with a Selector object in server side. The client side is similar with the server side, it also use a special thread to connect to server, read data, write data.
Now, we found sometimes the time that the socket channel object can't be accepted in server side in time. for example:
the client side:(output after socketchannel.finishConnect is true)
11:20:27.937 Finished connect to <remote:/127.0.0.1:9433,local:/127.0.0.1:3602> .
the server side:(output after serversocketchannel.accept method)
11:33:11.93 Accepted connection from /127.0.0.1:3602.
From the log, we knew that the client created a socket channel object and finished connect at 11:20:27.937 but selector object detected this OP_ACCEPT event and accept this socket channel at 11:33:11.93. this process need 13 minutes.
No server can accept this so long delay. this issue happen only when the machine is in high load.
I reproduce it by the below steps:
1, start 3 servers in one machine.
2, run 40 threads to access one server. the machine is in very high load, then quickly this issue happen.
by the way, the implement of server side is below:
while (!shutdown) {
try {
int readyCount;
try {
readyCount = selector.select();
} catch (java.nio.channels.ClosedSelectorException ex) {
readyCount = -1;
if (readyCount == -1 || isWindowsChannelBug4881228(readyCount)) {
// Reset the selector
logger.error("windows channel bug 4881228");
} else if (readyCount == 0) {
logger.debug("select wakeup");
} else {
Iterator keyIter = selector.selectedKeys().iterator();
while (keyIter.hasNext()) {
SelectionKey key = (SelectionKey) keyIter.next();
keyIter.remove();
if (key.isConnectable()) {
((ChannelConnection) key.attachment()).finishConnect();
if (!key.isValid()) {
continue;
if (key.isAcceptable()) {
ServerSocketChannel ssc = (ServerSocketChannel) key.channel();
try {
SSLEngine sslEngine = null;
if (ssc == sslSocketChannel) {
sslEngine = sslContext.createSSLEngine();
sslEngine.setWantClientAuth(true);
sslEngine.setUseClientMode(false);
ServerChannelConnection conn =
new ServerChannelConnection(this, ssc.accept(), sslEngine);
conn.setConnectTime(System.currentTimeMillis());
conn.registerForRead(selector);
} catch (IOException ex) {
if (!key.isValid()) {
continue;
if (key.isReadable()) {
try {
((ChannelConnection) key.attachment()).processInput();
catch (Throwable ex) {
logger.error(ex);
if (!key.isValid()) {
continue;
if (key.isWritable()) {
try {
((ChannelConnection) key.attachment()).processOutput();
catch (Throwable ex) {
IOException iex=new IOException(msg(FailedWriteResponse));
iex.initCause(ex);
logger.error(iex);
if (!key.isValid()) {
continue;
processPendingRequests();
catch (Throwable ex) {
logger.error(ex.getMessage(), ex);
try {
Thread.sleep(1000);
} catch (InterruptedException ex2) {
// ignore
The client side is similar with the up.
I can't understand it. Normally, the selector should detected OP_ACCEPT event quickly. but why not?
Anyone who met this issue?

Answer 1

You have an empty catch{} block for IOExceptions when handling isAcceptable(). So the prima facie presumption is that an error condition is arising, that you are ignoring. Fix that first and retest.
After that, if you still have a problem, I have some comments.
1. Create the SSLEngine and/or the ServerChannelConnection after accepting the connection, not before, and only if you got a non-null accepted channel. It is still valid for accept() to return null after you get OP_ACCEPT.
2. Get rid of the sleep() in the exception handler - what's that for?
3. select() for a specific timeout, not forever, and use the selectCount == 0 case to do something useful such as scanning for idle connections that you might want to drop.
3. Catch IOException explicitly as well as Throwable, in the outer loop, not per operation, and close the current key's channel if you get it. You can't do anything more with a channel that's had an IOException of any kind, except a SocketTimeoutException, and you won't get that in non-blocking mode.