lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gus Heck (JIRA)" <>
Subject [jira] [Commented] (SOLR-11654) TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to the ideal shard
Date Tue, 19 Jun 2018 18:31:00 GMT


Gus Heck commented on SOLR-11654:

The other additions were syntactic sugar, so whatever folks think there is fine. It just seemed
to me that varargs was likely just something nobody bothered to add yet, though certainly
it's great to discuss all of this. For the method that you pasted above I agree. It would
be a good idea to make a copy of the params and note that in the javadoc for clarity. I'm
not so sure about setting the type to SolrParams however since we then have to add error logic
to account for the fact that seParams takes a ModifiableSolrParams

> TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to the ideal
> --------------------------------------------------------------------------------------------
>                 Key: SOLR-11654
>                 URL:
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Major
>         Attachments: SOLR-11654.patch, SOLR-11654.patch, SOLR-11654.patch
> {{TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection}} looks up the Shard/Slice
to talk to for the given collection.  It currently picks the first active Shard/Slice but
it has a TODO to route to the ideal one based on the router configuration of the target collection.
 There is similar code in CloudSolrClient & DistributedUpdateProcessor that should probably
be refactored/standardized so that we don't have to repeat this logic.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message