[
https://issues.apache.org/jira/browse/HBASE-23744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey Jacoby updated HBASE-23744:
------------------------------------
Description:
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.
was:
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. 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
TestSimpleRpcExecutor.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.
> 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)