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