[
https://issues.apache.org/jira/browse/ZOOKEEPER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707536#action_12707536
]
Patrick Hunt commented on ZOOKEEPER-336:
----------------------------------------
1b) I expect the client to do the right thing, but as you are explicitly
forcing a particular behavior, one that may not
happen very often, I thought it was best to ensure it works. Otw going to be
hard bug to track down in production. (we
don't expect this code to be exercised very often, if at all). You should
submit everything as single patch, rather than open a
potential hole - also saves on the back/forth of multiple jiras.
3) ah, yes, I missed that aspect, good point. In that case you should remove
the cnxn from the ipmap during cnxn close operation.
Much like the factory.cnxns is being updated there. Of course it is a bit
tricker due to concurrency.
> single bad client can cause server to stop accepting connections
> ----------------------------------------------------------------
>
> Key: ZOOKEEPER-336
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-336
> Project: Zookeeper
> Issue Type: Improvement
> Components: c client, java client, server
> Reporter: Patrick Hunt
> Assignee: Henry Robinson
> Priority: Critical
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-336.patch, ZOOKEEPER-336.patch,
> ZOOKEEPER-336.patch
>
>
> One user saw a case where a single mis-programmed client was overloading the
> server with connections - the client was creating a huge number of sessions
> to the server. This caused all of the fds on the server to become used.
> Seems like we should have some way of limiting (configurable override) the
> maximum number of sessions from a single client (say 10 by default?) Also we
> should output warnings when this limit is exceeded (or attempt to exceed).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
