[
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481443#comment-14481443
]
Ben Craig commented on THRIFT-3084:
-----------------------------------
"That logic allows for maxConnections + 1 to be accepted."
It's worse than that. if you don't do anything fancy with TServerSocket, the
current logic allows for maxConnections + 1024 connections. TServerSocket sets
the backlog in the listen system call to 1024 by default. Sure, you may not
actually call 'accept()' on all 1024 of those, but the client on the other end
has received a SYN-ACK, and has sent an ACK and some other traffic to the
server. Those 1024 sockets in the servers backlog are also consuming resources.
So let's look at the problem a different way...
Suppose 'maxConnections' clients have already connected. What do you want the
behavior to be on the client side when they try to make the next connection?
The current behavior is that they basically stay in limbo until one of the
other connections clears up. What would you prefer the behavior be?
If you want the client to be disconnected, then that suggests that you want to
call accept(), but then immediately close() it if the server is at capacity.
Both the current implementation (for TThreadPoolServer at least) and the
suggested approach will do a reasonable job at preventing excessive threads and
file descriptors from being created. TThreadedServer could stand to be
improved either way though.
> 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)
