You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Viraj Jasani (Jira)" <ji...@apache.org> on 2020/07/13 07:44:00 UTC

[jira] [Comment Edited] (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=17156529#comment-17156529 ] 

Viraj Jasani edited comment on HBASE-23744 at 7/13/20, 7:43 AM:
----------------------------------------------------------------

Merged changes to master, branch-2 and branch-1. Since github is down, have not yet confirmed commit in UI but I was able to push the changes to upstream without issues.


was (Author: vjasani):
Merged changes to master, branch-2 and branch-1. Since github is down, have not yet confirmed commit in UI but I was able to push the changes manually.

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