You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Houston Putman (Jira)" <ji...@apache.org> on 2019/10/24 21:25:00 UTC
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16959228#comment-16959228 ]
Houston Putman commented on SOLR-13865:
---------------------------------------
I've created an initial PR for the migration. There's definitely stuff to clean up, but I think the bulk is done.
Current issues (as mentioned on the PR):
* {{NodesSysPropsCacher}} has a hack to inject testing sysProps, because {{TestInjection}} is not visible in the SolrJ package.
* The {{TestSQLHandler}} tests seem to be broken, not exactly sure how I have broken them.
Will try to clean stuff up and fix the two known issues over the next day or so.
Please let me know if I've done something wrong, or been too aggressive about moving. Also I just chose "routing" as the new package name in SolrJ, but I'm perfectly happy to change it if anyone has a better option.
> 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
> Time Spent: 10m
> 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