[
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481519#comment-14481519
]
James E. King, III commented on THRIFT-3084:
--------------------------------------------
I was strictly referring to the user space process resource allocation. You
are correct that the backlog on the server socket would fill up and it is up to
the implementer to decide how much of a backlog they want to service. This is
even a problem with TSimpleServer; the default backlog is 1024 but it can only
do one thing at a time. Providing backpressure seems like a reasonable
solution and that is what the backlog does, because those connections in the
backlog will eventually timeout if they are not serviced. None of this is in
user space however, because we haven't accepted them, so that is okay. A web
server will provide backpressure by replying with a HTTP 503 response and
closing the connection. We have no such low level handshake where the server
could send a TTransportException(TOO_BUSY) to the client today.
Having a barrier as I suggested will ensure that in the user-space process only
that many concurrent client sockets will be allowed to be connected and no more
(unless the limit is reduced while there are more clients connected than the
new limit, then they will drain off), whereas without the barrier we will allow
maxConnections + 1 for a TThreadPoolServer, which is incorrect, and an
unlimited number of connections for a TThreadedServer, which is also nasty.
Instead of implementing it in the way I proposed, we could add a semaphore to
TThreadedServer such that it has the same behavior as TThreadPoolServer,
whereby it is clearly documented that whatever maximum for threads or
connections are specified, it will be possible to have one more in user space
that is blocking on the maximum. This is perhaps a smaller overall change, but
less correct.
> 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)
