You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Geoffrey Jacoby (Jira)" <ji...@apache.org> on 2020/01/27 18:25:00 UTC

[jira] [Updated] (HBASE-23744) FastPathBalancedQueueRpcExecutor should enforce queue length of 0

     [ 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)