[ 
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266573#comment-14266573
 ] 

Nick Dimiduk commented on HBASE-12071:
--------------------------------------

What's the thinking on increasing the number of queues to 2?

{noformat}
-   this.priorityExecutor =
-     priorityHandlerCount > 0 ? new BalancedQueueRpcExecutor("Priority", 
priorityHandlerCount,
-       1, maxQueueLength, conf, abortable) : null;
+    // Create 2 queues to help priorityExecutor be more scalable.
+    this.priorityExecutor = priorityHandlerCount > 0 ?
+        new BalancedQueueRpcExecutor("Priority", priorityHandlerCount, 2, 
maxQueueLength) : null;
{noformat}

It's probably worth while turning priority into a protobuf enum. I don't know 
if we can do that, given that RequestHeader.priority is already defined as a 
uint32. The docs say valid enum value range is 32-bit signed int, so maybe we'd 
have to deprecate the existing field? Someone who knows more about protobuf, 
any thoughts here?

Other question: can we move the QosPriority annotations over to the 
BlockingInterfaces? Maybe not since they're generated protobuf...

Otherwise, +1. You test all this out [~syuanjiang]? Working as expected?

> Separate out thread pool for Master <-> RegionServer communication
> ------------------------------------------------------------------
>
>                 Key: HBASE-12071
>                 URL: https://issues.apache.org/jira/browse/HBASE-12071
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 2.0.0, 1.1.0
>            Reporter: Sudarshan Kadambi
>            Assignee: Stephen Yuan Jiang
>              Labels: reliablity
>             Fix For: 2.0.0, 1.1.0
>
>         Attachments: HBASE-12071.v1-branch-1.patch, 
> HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, 
> HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, 
> HBASE-12071.v5-master.patch
>
>
> Over in HBASE-12028, there is a discussion about the case of a RegionServer 
> still being alive despite all its handler threads being dead. One outcome of 
> this is that the Master is left hanging on the RS for completion of various 
> operations - such as region un-assignment when a table is disabled. Does it 
> make sense to create a separate thread pool for communication between the 
> Master and the RS? This addresses not just the case of the RPC handler 
> threads terminating but also long-running queries or co-processor executions 
> holding up master operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to