[jira] [Commented] (SOLR-11654) TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to the ideal shard

["Gus Heck (JIRA)" <ji...@apache.org>]

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

Gus Heck commented on SOLR-11654:
---------------------------------

This has been dangling a bit too long, so attaching what I have so far. I feel pretty good that I've got code in place that selects an appropriate shard, and things seem to not break, but trying to write a test for this code has been a mess... I've been lost in the weeds chasing the notion that TrackingShardHandlerFactory could be used to track which shards requests were sent to, but based on everything I can find updates never touch shardHandlers so that's a dead end. The in-code documentation on ShardRequest and ShardHandler, and ShardHandlerFactory and pretty much everything having anything to do with shard requests is virtually non existent. HttpShardHandler has the seemingly odd property that many of the request making methods are on the factory, not the object produced by the factory... In any case I think something analogous to TrackingShardHandlerFactory for tracking updates is required to properly test this, probably a custom URP, though it needs to be configured after DistributedUpdateProcessor to ensure it isn't skipped on the sub-requests.

> 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
>            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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org