[ 
https://issues.apache.org/jira/browse/SOLR-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15583110#comment-15583110
 ] 

Christine Poerschke commented on SOLR-6730:
-------------------------------------------

Noble and I discussed offline re: SOLR-6730 and SOLR-8146 overlaps and 
differences. I will try to summarise here as bullet points, [~noble.paul] 
please add or correct if i missed or misunderstood something.

* The use case and motivation for the {{select?replicaAffinity=(node|host)}} 
part of SOLR-6730 was to reduce the number of JVMs hit by a given search since 
the more JVMs are hit, the higher the chance of hitting a garbage collection 
pause in one of many JVMs.

* The use case and motivation for the {{replicaAffinity.hostPriorities=...}} 
part of SOLR-6730 was to preferentially direct requests from the same 
user/source to certain areas of the cloud.
** The implementation of the {{replicaAffinity.hostPriorities=...}} approach 
requires configuration somewhere i.e. a list of which hosts to prioritise.
** No matter where it is stored, maintaining configuration can be cumbersome as 
collections and hosts change over time.

* The objective of directing requests from the same user/source to certain 
areas of the cloud can be achieved without configuration, and the objective of 
reducing the number of JVMs hit by a search can pretty much be achieved that 
way also.
** Approach outline:
*** Two numeric parameters ('seed' and 'mod') are optionally added to each 
request.
*** The two parameters 'place' the requests within the cloud, e.g. for 
{{mod=9}} any seed between 0 and 8 would be valid and {{seed=6}} would 'place' 
the request with the 7th of 9 replicas, or more realistically the 3rd of 3 
replicas.
*** seed-plus-mod placement automatically adjusts when the number of replicas 
changes i.e. (seed=2,mod=6) would be 3rd-of-6 or 2nd-of-4 or 2nd-of-3 or 
1st-of-2 placement.
*** SOLR-6730 here would likely be abandoned in favour of the approach outlined.

* What is common to SOLR-6730 and SOLR-8146:
** optional parameters would support changing of the existing behaviour
** existing behaviour is maintained if the optional parameters are not supplied

* What is different between SOLR-6730 and SOLR-8146:
** point-of-use of the optional parameter is HttpShardHandler\[Factory\] for 
SOLR-6730
** point-of-use of the optional parameter is CloudSolrClient (and 
HttpShardHandler\[Factory\]?) for SOLR-8146

* Next steps:
1. SOLR-8332 to factor HttpShardHandler\[Factory\]'s url shuffling out into a 
ReplicaListTransformer class
2. creation of additional ReplicaListTransformer implementations corresponding 
to the approach outlined above

> select?replicaAffinity=(node|host) and replicaAffinity.hostPriorities support
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-6730
>                 URL: https://issues.apache.org/jira/browse/SOLR-6730
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Christine Poerschke
>            Assignee: Christine Poerschke
>            Priority: Minor
>
> If no shards parameter is supplied with a select request then sub-requests 
> will go to a random selection of live solr nodes hosting shards for the 
> collection of interest. All sub-requests must complete before results can be 
> collated i.e. the slowest sub-request determines how fast the search 
> completes.
> Use of optional replicaAffinity can reduce the number of JVMs hit by a given 
> search (the more JVMs are hit, the higher the chance of hitting a garbage 
> collection pause in one of many JVMs). Preferentially directing requests to 
> certain areas of the cloud can also be useful for debugging or when some 
> replicas reside on 'faster' machines.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to