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

ASF GitHub Bot commented on PHOENIX-1457:
-----------------------------------------

Github user JamesRTaylor commented on a diff in the pull request:

    https://github.com/apache/phoenix/pull/55#discussion_r27270740
  
    --- Diff: 
phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/PhoenixRpcScheduler.java 
---
    @@ -40,28 +40,34 @@
         private static final int DEFAULT_MAX_CALLQUEUE_LENGTH_PER_HANDLER = 10;
     
         private RpcScheduler delegate;
    -    private int minPriority;
    -    private int maxPriority;
    -    private RpcExecutor callExecutor;
    +    private int indexPriority;
    +    private int metadataPriority;
    +    private RpcExecutor indexCallExecutor;
    +    private RpcExecutor metadataCallExecutor;
         private int port;
     
    -    public PhoenixIndexRpcScheduler(int indexHandlerCount, Configuration 
conf,
    -            RpcScheduler delegate, int minPriority, int maxPriority) {
    +    public PhoenixRpcScheduler(int indexHandlerCount, int 
metadataHandlerCount, Configuration conf,
    --- End diff --
    
    I don't think declaring a range of priorities future proofs this as no one 
will know we've reserved that range - folks don't even read docs in general. If 
if they did happen upon it, there's nothing that'll enforce that they respect 
it. Better IMO to declare that we're using two explicit priorities. If folks 
need to change them, it pretty straightforward as it's two documented config 
parameters.
    
    The current implementation is simpler, removes a number of configs (we 
already have too many), and meets the needs.


> Use high priority queue for metadata endpoint calls
> ---------------------------------------------------
>
>                 Key: PHOENIX-1457
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1457
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>              Labels: 4.3.1
>
> If the RS hosting the system table gets swamped, then we'd be bottlenecked 
> waiting for the response back before running a query when we check if the 
> metadata is in sync. We should run endpoint coprocessor calls for 
> MetaDataService at a high priority to avoid that.



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

Reply via email to