[
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481375#comment-14481375
]
James E. King, III commented on THRIFT-3084:
--------------------------------------------
That will not limit the number of concurrent clients allowed to connect at once
properly:
* Server is at maxConnections clients.
* serve() accept()s another TTransport (client)
* serve() blocks(?) waiting to insert the new client into the thread pool.
That logic allows for maxConnections + 1 to be accepted. Further, it does not
help the TThreadedServer maintain any limits.
Having a controllable barrier immediately before accept() would allow any
implementation to enable or disable the accept barrier and subsequently exactly
control the upper bound on the number of concurrent accepted connections to the
server.
> C++ add concurrent client limit to threaded servers
> ---------------------------------------------------
>
> Key: THRIFT-3084
> URL: https://issues.apache.org/jira/browse/THRIFT-3084
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Library
> Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2
> Reporter: James E. King, III
>
> The TThreadedServer and TThreadPoolServer do not impose limits on the number
> of simultaneous connections, which is not useful in production as bad clients
> can drive a server to consume too many file descriptors or have too many
> threads.
> 1. Add a barrier to TServerTransport that will be checked before accept().
> 2. In the onClientConnected override (see THRIFT-3083) if the server reaches
> the limit of the number of accepted clients, enable the barrier.
> 3. In the onClientDisconnected override if the count of connected clients
> falls below the maximum concurrent limit, clear the barrier. This will allow
> the limit to be changed dynamically at runtime (lowered) with drain off
> clients until more can be accepted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
