[ https://issues.apache.org/jira/browse/ZOOKEEPER-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884548#action_12884548 ]
Patrick Hunt commented on ZOOKEEPER-517: ---------------------------------------- I noticed another issue in this same area: {noformat} if ((k.readyOps() & SelectionKey.OP_ACCEPT) != 0) { SocketChannel sc = ((ServerSocketChannel) k .channel()).accept(); InetAddress ia = sc.socket().getInetAddress(); int cnxncount = getClientCnxnCount(ia); if (maxClientCnxns > 0 && cnxncount >= maxClientCnxns){ LOG.warn("Too many connections from " + ia + " - max is " + maxClientCnxns ); sc.close(); {noformat} Notice that if macclientcnxns is exceeded we close the connection - iirc default linger time on linux is typically 60seconds. So if we have a mis-behaving client we can still run into trouble ("still" meaning we added this code to keep clients from DOS attacking the server) with TIME_WAIT state on the tcp connection. We need to set the linger time down to 0 in this case before closing. > NIO factory fails to close connections when the number of file handles run > out. > ------------------------------------------------------------------------------- > > Key: ZOOKEEPER-517 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-517 > Project: Zookeeper > Issue Type: Bug > Components: server > Reporter: Mahadev konar > Priority: Critical > Fix For: 3.3.2, 3.4.0 > > > The code in NIO factory is such that if we fail to accept a connection due to > some reasons (too many file handles maybe one of them) we do not close the > connections that are in CLOSE_WAIT. We need to call an explicit close on > these sockets and then close them. One of the solutions might be to move doIO > before accpet so that we can still close connection even if we cannot accept > connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.