[
https://issues.apache.org/jira/browse/SOLR-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16518222#comment-16518222
]
David Smiley commented on SOLR-11654:
-------------------------------------
This new test takes a long time and I don't want it to take so long on average.
Randomization can help here so I chose shards & replicas randomly with the
high end being the numbers you chose. The patch shows this (and other
changes). However this test failed on me on waitFor the collections after the
doc is added. Try seed -Dtests.seed=613B69692267C615 Can you investigate
[~gus_heck]? The # shards & replicas should have no bearing on the test up to
this point.
> 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, 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
