[
https://issues.apache.org/jira/browse/HBASE-8884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13761070#comment-13761070
]
stack commented on HBASE-8884:
------------------------------
Looking more at this patch, we effectively double the number of threads we have
running a Call. A handler, which is a thread does nothing but start the
CallRunner thread added in this patch. And if I read this patch right, we
actually have lost control of the bounding on the number of threads we had
running at any one time. The handler does takes from the queue, starts a
thread, then loops and there is nothing to prevent it taking another CallRunner
from the queue and starting it, and so on.
I would suggest that CallRunner NOT be a thread (before this patch Handler did
the work, now it creates a new thread to do the work).
Could we fix it so RpcScheduler does not have to reach back into RpcServer to
get the CallRunner type? Maybe CallRunner should be outside of RpcServer.
RpcServer has too many inner classes as it is.
Its a pity this stuff is in the Interface:
+ /** Retrieves length of the general queue for metrics. */
+ int getGeneralQueueLength();
+
+ /** Retrieves length of the priority queue for metrics. */
+ int getPriorityQueueLength();
+
+ /** Retrieves length of the replication queue for metrics. */
+ int getReplicationQueueLength();
It hardcodes three queue types thereby constraining the types of scheduler that
can be implemented.
The gymnastics w/ MONITORED_RPC, the thread local, and how we get it in
CallRunner to set state is 'interesting'. It says that we are setting the
state on the handler but that is not so, right, if the handler is running the
CallRunner...we are setting state of a CallRunner... and it looks like a
Handler could be running multiple of them. What is this doing? Making it so
handler state in the UI shows properly?
Thanks.
> Pluggable RpcScheduler
> ----------------------
>
> Key: HBASE-8884
> URL: https://issues.apache.org/jira/browse/HBASE-8884
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC
> Reporter: Chao Shi
> Assignee: Chao Shi
> Fix For: 0.98.0
>
> Attachments: hbase-8884.patch, hbase-8884-v2.patch,
> hbase-8884-v3.patch, hbase-8884-v4.patch, hbase-8884-v5.patch,
> hbase-8884-v6.patch, hbase-8884-v7.patch, hbase-8884-v8.patch
>
>
> Today, the RPC scheduling mechanism is pretty simple: it execute requests in
> isolated thread-pools based on their priority. In the current implementation,
> all normal get/put requests are using the same pool. We'd like to add some
> per-user or per-region level isolation, so that a misbehaved user/region will
> not saturate the thread-pool and cause DoS to others easily. The idea is
> similar to FairScheduler in MR. The current scheduling code is not standalone
> and is mixed with others (Connection#processRequest). The issue is the first
> step to extract it to an interface, so that people are free to write and test
> their own implementations.
> This patch doesn't make it completely pluggable yet, as some parameters are
> pass from constructor. This is because HMaster and HRegionServer both use
> RpcServer and they have different thread-pool size config. Let me know if you
> have a solution to this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
