murblanc commented on a change in pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r459773371
########## File path: solr/core/src/java/org/apache/solr/cloud/gumi/PropertyKeyFactory.java ########## @@ -0,0 +1,34 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.solr.cloud.gumi; + +/** + * Factory used by the plugin to create property keys to request property values from Solr + */ +public interface PropertyKeyFactory { + /** + * Returns a property key allowing to request the number of cores. There are no parameters for this key. + */ + CoresCountPropertyKey createCoreCountKey(); + + /** + * Returns a property key allowing to request the value of a system property (sorry property used twice in two different + * contexts). The parameter is the name of the system property to retrieve. + */ + SystemPropertyPropertyKey createSystemPropertyKey(String systemPropertyName); Review comment: @sigram @noblepaul I need some help here... I assume "metrics" are the things that look like `"metrics:solr.core.Collection.shardXX.replicaYY:actual.metric.name"`). They don't seem to be at the "node level" but relate to a replica (maybe to other things). Do you know how getting the corresponding metric value is implemented? Is it sent from Overseer running Autoscaling to the node hosting the relevant replica for evaluation? I wonder how the `PropertyKey` instances (that will include a `MetricsPropertyKey` soon) should be grouped by the plugin when it requests to have values fetched so that the fetching is efficient (I assume plugins will be single threaded and do synchronous calls, to keep things simple). In other words, I want to allow limiting to a single exchange with each node for fetching all data (all properties, including metrics), so I need to let the plugin group its requests accordingly. In the first commit, the `Node` class had a `getProperties()` method. I was considering that the plugin knows what it wants to ask from each `Node` and can group these requests and send only once per node. Now if the plugin also needs for example `metrics:solr.core.testEstimatedIndexSize_collection.shard1.replica_n2:SEARCHER.searcher.indexCommitSize` (random value copied from a test), and if that metric requires a round trip with the node hosting that specific replica, there's no easy way for the plugin to group requests per `Node` (I don't want the plugin to have to do complicated groupings on data just to request metrics). Therefore I'm considering moving the `getProperties()` away from `Node` and into a central place, and having each property key specify what context it is for: the whole cluster, a specific node, a specific collection, a specific shard or a specific replica. I assume that covers current needs. This way a single call to get all the property values can be dispatched efficiently by the implementation by grouping all keys that need to go to the same node into a single message. (in order not to prematurely optimize, I'm resisting and not introducing wildcard constructs such as `#EACH`... under the assumption that key building is of negligible cost compared to the shipping to the nodes and response collection, and we will need to expand wildcard requests anyway). Assuming the metric target is specified independently (by having a reference to the corresponding API object), a metric is then fully defined by passing in the metric name? (the `SEARCHER.searcher.indexCommitSize`). That's all I need to pass then in the corresponding `PropertyKeyFactory` metric building call? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
