[
https://issues.apache.org/jira/browse/KUDU-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244610#comment-16244610
]
Todd Lipcon commented on KUDU-2211:
-----------------------------------
This is definitely a reasonable idea, and would make sense to reuse the same
thread pooling for both use cases. The one major thing that the RPC service
pool has that the general ThreadPool does not is a priority-queue based
queueing scheme. Additionally, it does LIFO waking of threads, which
util/thread_pool doesn't.
The LIFO thread waking would be nice to have on the other thread pool as well
([~adar] was talking about looking at this). The question remains whether we
can retain the priority-queue behavior for RPC threads while not regressing
performance and feature set of the THreadPool implementation.
> improve the thread pool for rpc service
> ---------------------------------------
>
> Key: KUDU-2211
> URL: https://issues.apache.org/jira/browse/KUDU-2211
> Project: Kudu
> Issue Type: Improvement
> Components: rpc
> Affects Versions: 1.5.0
> Reporter: HeLifu
> Priority: Minor
>
> in user mail list, Lee King modified his config of 'rpc_num_threads' to 128
> for consensus stability, but it will waste too much resource. maybe we could
> do some improvement:
> 1) different rpc service use different config of 'rpc_num_thread';
> 2) use 'threadpool' instead of 'std::vector<scoped_refptr<kudu::Thread> >
> threads_', just like negotiation pool does;
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
