Github user jyates commented on a diff in the pull request: https://github.com/apache/phoenix/pull/55#discussion_r27153366 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/hbase/index/ipc/PhoenixRpcSchedulerFactory.java --- @@ -62,30 +62,59 @@ public RpcScheduler create(Configuration conf, RegionServerServices services) { return delegate; } + // get the index priority configs int indexHandlerCount = conf.getInt(QueryServices.INDEX_HANDLER_COUNT_ATTRIB, QueryServicesOptions.DEFAULT_INDEX_HANDLER_COUNT); - int minPriority = getMinPriority(conf); - int maxPriority = conf.getInt(QueryServices.MAX_INDEX_PRIOIRTY_ATTRIB, QueryServicesOptions.DEFAULT_INDEX_MAX_PRIORITY); - // make sure the ranges are outside the warning ranges - Preconditions.checkArgument(maxPriority > minPriority, "Max index priority (" + maxPriority - + ") must be larger than min priority (" + minPriority + ")"); - boolean allSmaller = - minPriority < HConstants.REPLICATION_QOS - && maxPriority < HConstants.REPLICATION_QOS; - boolean allLarger = minPriority > HConstants.HIGH_QOS; - Preconditions.checkArgument(allSmaller || allLarger, "Index priority range (" + minPriority - + ", " + maxPriority + ") must be outside HBase priority range (" - + HConstants.REPLICATION_QOS + ", " + HConstants.HIGH_QOS + ")"); + int indexMinPriority = getIndexMinPriority(conf); + int indexMaxPriority = conf.getInt(QueryServices.MAX_INDEX_PRIOIRTY_ATTRIB, QueryServicesOptions.DEFAULT_INDEX_MAX_PRIORITY); + validatePriority(indexMinPriority, indexMaxPriority); + + // get the metadata priority configs + int metadataHandlerCount = conf.getInt(QueryServices.INDEX_HANDLER_COUNT_ATTRIB, QueryServicesOptions.DEFAULT_METADATA_HANDLER_COUNT); + int metadataMinPriority = getMetadataMinPriority(conf); + int metadataMaxPriority = conf.getInt(QueryServices.MAX_INDEX_PRIOIRTY_ATTRIB, QueryServicesOptions.DEFAULT_METADATA_MAX_PRIORITY); --- End diff -- I can see us wanting a reserved range for metadata updates - say 10 different numbers - so we don't have to worry about conflicting with anything else that needs its own priority in the future. Its easy to get into situations, especially if everyone is carefully watching these numbers and fully know whats going on, to get into situations where you have META = 1, SOME_FEATURE=2, OTHER_META=3, etc. A reserved range is just safer for the future and is likely to never be changed in the configuration, unless people already to priority changing, which is unlikely given how hard it was for us :). However, having the configuration is necessary, regardless of range or a single value, to ensure people can make it work with their existing installations (and as proof against HBase invading our range space by accident).
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---