[ https://issues.apache.org/jira/browse/PHOENIX-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383079#comment-14383079 ]
ASF GitHub Bot commented on PHOENIX-1457: ----------------------------------------- Github user twdsilva commented on a diff in the pull request: https://github.com/apache/phoenix/pull/55#discussion_r27269432 --- 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 modified the controller factory to use create a chain of controllers, which was easy I could just have them extend DelegatingPayloadCarryingRpcController. However for the PhoenixRpcScheduler needs to implement getGeneralQueueLength and getActiveRpcHandlerCount which need queue lengths and counts of the indexCallExecutor and metadataCallExecutor . Do you think it would be easier to have a map from prioirity to queue and then in dispatch() we just lookup the queue based on the priority (and if its not found in the map call delegate.dispatch(callTask) )? > 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)