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

Reply via email to