[
https://issues.apache.org/jira/browse/THRIFT-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481530#comment-14481530
]
Randy Abernethy commented on THRIFT-3084:
-----------------------------------------
Prior to addressing these issues I suggest considering the removal of
TThreadedServer. If a server is not truly differentiating then we are just
confusing users by having it and adding work for the contributors/maintainers.
What value add does TThreadedServer provide over TThreadPoolServer? With a few
lines of code we could easily provide features that makde TThreadPoolServer
behave like TThreadedServer when desired (you can do it presently by adding
threads to the pool with server events as Ben suggests).
Recommendations:
- We remove TThreadedServer from the system and focus on getting a single
"threaded" server right (TThreadPoolServer seems like the correct starting
point).
By avoiding undifferentiated servers we also eliminate any need for
complicating the server code with shared base implementations.
TNonBlockingServer is differentiating and should share the TServer interface
and little else, TSimpleServer should be simple and free of code hierarchies by
design and TThreadPoolServer should stand as the threaded server and
encapsulate good threading practices in one simple package, with pooling as an
optimization.
Thoughts?
> 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)
