magibney commented on a change in pull request #677: SOLR-13257: support for
stable replica routing preferences
URL: https://github.com/apache/lucene-solr/pull/677#discussion_r302357020
##########
File path:
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java
##########
@@ -449,9 +556,83 @@ private static boolean hasReplicaType(Object o, String
preferred) {
}
}
+ private final ReplicaListTransformerFactory randomRltFactory = (String
configSpec, SolrQueryRequest request,
+ ReplicaListTransformerFactory fallback) ->
shufflingReplicaListTransformer;
+ private ReplicaListTransformerFactory stableRltFactory;
+ private ReplicaListTransformerFactory defaultRltFactory;
+
+ /**
+ * Private class responsible for applying pairwise sort based on inherent
replica attributes,
+ * and subsequently reordering any equivalent replica sets according to
behavior specified
+ * by the baseReplicaListTransformer.
+ */
+ private static final class TopLevelReplicaListTransformer implements
ReplicaListTransformer {
+
+ private final NodePreferenceRulesComparator replicaComp;
+ private final ReplicaListTransformer baseReplicaListTransformer;
+
+ public TopLevelReplicaListTransformer(NodePreferenceRulesComparator
replicaComp, ReplicaListTransformer baseReplicaListTransformer) {
+ this.replicaComp = replicaComp;
+ this.baseReplicaListTransformer = baseReplicaListTransformer;
+ }
+
+ @Override
+ public void transform(List<?> choices) {
Review comment:
I had to think about this for a minute, when I wrote it, and again now :-)
...
I think it actually _would_ be different. The key is that the affinity code
is always based on the same absolute order; it's only the _rotation_ that
changes. And if we apply the rotation to the overall list before applying other
preferences, the stability of the sort doesn't help us.
Take for example a situation with replicas [A, B, C, D, E]. For the sake of
argument, let's say that B and C will end up being tied for "most preferred",
according to the inherent preference comparators. The "affinity"
transformation, applied at the top level, would sort the replicas: [A, B, C, D,
E], then rotate them according to some explicitly specified or hash-derived int
param. The problem is that there's only one in 5 possible top-level rotations
would result in C being ranked first: [C, D, E, A, B]. So the resulting order
would be deterministic, but wouldn't distribute load evenly.
Applying the affinity rotation "in post" does end up distributing load
evenly, since you're always rotating mod the number of _equivalent_ replicas
per group.
----------------------------------------------------------------
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:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
