You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Tomas Eduardo Fernandez Lobbe (Jira)" <ji...@apache.org> on 2019/10/28 23:46:00 UTC
[jira] [Resolved] (SOLR-13865) Centralize the replica-choosing
strategy for distributed requests across Solr
[ https://issues.apache.org/jira/browse/SOLR-13865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tomas Eduardo Fernandez Lobbe resolved SOLR-13865.
--------------------------------------------------
Fix Version/s: 8.4
master (9.0)
Resolution: Fixed
> Centralize the replica-choosing strategy for distributed requests across Solr
> -----------------------------------------------------------------------------
>
> Key: SOLR-13865
> URL: https://issues.apache.org/jira/browse/SOLR-13865
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, streaming expressions
> Affects Versions: master (9.0), 8.4
> Reporter: Houston Putman
> Priority: Minor
> Fix For: master (9.0), 8.4
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In general, all parts of Solr that choose a replica of a shard to send a request to should use similar logic.
> From what I can tell, the {{HttpShardHandlerFactory.NodePreferenceRulesComparator}} is the most comprehensive replica request routing strategy within Solr. It would be great if this logic could be moved to the SolrJ package, so that it could be used across more of solr. Forms of this same decision making are found in many places, such as Streaming Expressions and SolrJ Clients ([SOLR-12217|https://issues.apache.org/jira/browse/SOLR-12217]). There's no reason that each should implement their own logic when they could easily share one. That way, additional routing parameters can be added in one place and be available for all types of requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org