[
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491675#comment-14491675
]
James E. King, III commented on THRIFT-3084:
--------------------------------------------
I agree, the difference between the ThreadedServer and the ThreadPoolServer is
negligible. The ThreadedServer could simply vanish, and technically if one can
live with the fact that the ThreadPoolServer accepts() one more connection than
the thread pool can hold then THRIFT-3084 may not be necessary, however I like
that with the change, we will not accept() more clients than we can handle, and
let the OS handle the overflow with the listen backlog. A TThreadPoolServer
with a pool size of 1 is quite similar to a simple server except it is using a
separate thread for processing. In the end, we probably only need one threaded
server that can admit [1..n] simultaneous clients. If that is the case, I
agree with you, TServerFramework would simply roll into a single server that
would be able to replace all three and provide the same functionality. I would
be happy to turn the crank to that one more time as a follow-on to the current
pipeline of changes.
Consolidating the serve loop and extracting the essence of onClientConnected
and onClientDisconnected made it much more clear that the similarities between
these servers is quite high.
As pointed out elsewhere, consolidating the servers into one would break
backwards compatibility for the other two unless adapters were provided and
that was seen as the only negative I can think of.
> 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
> Attachments: THRIFT-3084-on-3083.v2.patch
>
>
> 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.
> With TThreadPoolServer one can set the limit on the number of threads,
> however the server will use one additional file descriptor because the
> serve() routine does not block until after accepting the threadManager size +
> 1 sockets.
> With TThreadedServer there was no built-in way to throttle.
> Give the serve() loop is the only code capable of adding a client, the
> solution is to add a Monitor to the TServerFramework and check the number of
> concurrent clients immediately before calling TServerTransport::accept() to
> get another client, and to track the number of clients that are still alive
> (their smart pointer hasn't been destroyed).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
