[
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: [email protected]
For additional commands, e-mail: [email protected]
