You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Xu Cang (Jira)" <ji...@apache.org> on 2020/01/28 19:59:00 UTC
[jira] [Commented] (HBASE-23744) FastPathBalancedQueueRpcExecutor
should enforce queue length of 0
[ https://issues.apache.org/jira/browse/HBASE-23744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025408#comment-17025408 ]
Xu Cang commented on HBASE-23744:
---------------------------------
The idea you showed in PR makes sense to me.
Just wondering, is there another way to properly "temporarily prevent writes on cluster" such as disabling PRC handling ?
Setting the callqueue.length to 0 is a bit subtle to indicate the fact we want to disable writes. If we do so, could you please add a one sentence comment in FastPathBalancedQueueRpcExecutor class? thanks.
[~gjacoby]
> FastPathBalancedQueueRpcExecutor should enforce queue length of 0
> -----------------------------------------------------------------
>
> Key: HBASE-23744
> URL: https://issues.apache.org/jira/browse/HBASE-23744
> Project: HBase
> Issue Type: Bug
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Minor
>
> FastPathBalancedQueueRpcExecutor allows RPC requests to skip the RPC queue and get worked by an available handler under certain circumstances.
> Relatedly, the hbase.ipc.server.max.callqueue.length parameter can be set to 0, including dynamically. This can be useful to temporarily prevent writes on a cluster.
> When this is the case the executor is supposed to block all dispatching. However, the FastPathBalancedQueueRpcExecutor will still dispatch the request if one of the "fast path" handlers is available on its stack. This both isn't the desired effect, and also makes TestSimpleRpcScheduler.testSoftAndHardQueueLimits unstable when it checks the queue length 0 behavior.
> A simple fix is just to check max queue length > 0 before FastPathBalancedQueueRpcExecutor pops the fast handler off the stack.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)