[
https://issues.apache.org/jira/browse/PHOENIX-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383163#comment-14383163
]
ASF GitHub Bot commented on PHOENIX-1457:
-----------------------------------------
Github user jyates commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/55#discussion_r27271159
--- 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 --
And if we ever want to add different priorities for different indexes? Or
for different metadata tables? Or some other special tables (e.g. higher
priority tables as a logical construct). But ok, we can just assign each a
number as it comes up... that's never been weird for any other use case
::sarcasm::
> removes a number of configs
The number needs to be configurable to support installations where people
are using priorities for other things that aren't necessarily phoenix (as I
mentioned elsewhere), so having an upper and a lower for each isn't really that
big of a deal, IMHO.
> If if they did happen upon it, there's nothing that'll enforce that they
respect it
Except their cluster becoming unusable.
> Better IMO to declare that we're using two explicit priorities
Which is again, buried somewhere in the docs. Its fine to say that they
claim a range in the same place and then add a link to a 'you can configure it
here', but maybe I'm mistaken in what users want?
> 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)
