[
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.
