[
https://issues.apache.org/jira/browse/SOLR-14079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995589#comment-16995589
]
Yonik Seeley commented on SOLR-14079:
-------------------------------------
bq. The patch is using different but constant async id's for the different
stages.
That's just the test using the constant async ids for the different split calls.
bq. is there a fundamental reason this can't work async
We could use an async call and then wait for it (effectively turning it into a
synchronous call), but at that point in the code, it is synchronous behavior we
want (we can't proceed until we know the ranges for the new sub-shards.)
I'm new to the Overseer (I've successfully avoided it before ;-), so my
assumption on async calls is that I just didn't know how to use the API
properly, and that the response looks different when using async. Because of
this, the returned "ranges" wasn't found. If there are bugs/problems with
async calls, or other bugs in SplitShardCmd, then those can be handled in
additional JIRA issues.
> SPLITSHARD splitByPrefix doesn't work in async mode
> ---------------------------------------------------
>
> Key: SOLR-14079
> URL: https://issues.apache.org/jira/browse/SOLR-14079
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 8.3
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
> Priority: Major
> Fix For: 8.4
>
> Attachments: SOLR-14079.patch
>
>
> If you specify async=whatever in conjunction with splitByPrefix, the ranges
> are calculated by the shard leader, but that information does not make it
> back to the overseer and the split proceeds to just split down the middle.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
