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

David Smiley commented on SOLR-11654:
-------------------------------------

Looking at your patch.  getLeaderNode I noticed doesn't pass along "slice" to 
the constructor of RetryNode (last param).  It probably should do so for 
routeDocToSlice, but lookupShardLeadersOfCollections I guess null (what's 
happening today).  I'm not completely clear on the implications yet.

Hey [~shalinmangar] or anyone who knows SolrCloud well, do you know if there 
are tests for ensuring the doc routing goes right to the correct shard leader 
instead of being arbitrary?  I suppose it's fundamental to DURP but in 
CloudSolrClient AFAIK this is an optimization so perhaps there's a test for 
that?  We're not sure how to test this since it's an internal routing thing.  
See Gus's most recent comment above.  I directed Gus at 
TrackingShardHandlerFactory but didn't realize it's a search-only tracker not 
for updates (ouch).

> TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to 
> the ideal shard
> --------------------------------------------------------------------------------------------
>
>                 Key: SOLR-11654
>                 URL: https://issues.apache.org/jira/browse/SOLR-11654
>             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
>
>
> {{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
(v7.6.3#76005)

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

Reply via email to