[
https://issues.apache.org/jira/browse/SOLR-17971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126915#comment-18126915
]
Amrit Sarkar edited comment on SOLR-17971 at 10/14/26 4:10 AM:
---------------------------------------------------------------
Reproduced this. With the Overseer disabled, sub-command results go to
{{DistributedApiAsyncTracker}}, so {{waitAsyncRequests()}} never finds them in
the Overseer maps. Two effects:
* the command always waits the full {{maxWaitSeconds}} before returning
* the async ids are never cleared and pile up under
{{/distributedapi/async/persistent}}
PR: https://github.com/apache/solr/pull/5127
The fix branches on the mode the same way {{REQUESTSTATUS}} does in
{{ClusterCommands}}. In distributed mode it calls {{deleteSingleAsyncId()}},
which confirms the task is done and removes it in one call. I used that instead
of a {{REQUESTSTATUS}} request per id since it's the same lookup.
Added {{testRebalanceLeadersClearsAsyncIds}} to {{TestRebalanceLeaders}}.
Without the fix it fails in distributed mode with 29 leftover ids; it passes in
both modes with it.
[~dsmiley], would you mind taking a look?
was (Author: [email protected]):
Reproduced this. With the Overseer disabled, sub-command results go to
{{DistributedApiAsyncTracker}}, so {{waitAsyncRequests()}} never finds them in
the Overseer maps. Two effects:
* the command always waits the full {{maxWaitSeconds}} before returning
* the async ids are never cleared and pile up under
{{/distributedapi/async/persistent}}
PR: https://github.com/apache/solr/pull/5127
The fix branches on the mode the same way {{REQUESTSTATUS}} does in
{{ClusterCommands}}. In distributed mode it calls {{deleteSingleAsyncId()}},
which confirms the task is done and removes it in one call. I used that instead
of a {{REQUESTSTATUS}} request per id since it's the same lookup.
Added {{testRebalanceLeadersClearsAsyncIds}} to {{TestRebalanceLeaders}}.
Without the fix it fails in distributed mode with 29 leftover ids; it passes in
both modes with it.
> REBALANCELEADERS command is horribly slow with distributed cluster processing
> -----------------------------------------------------------------------------
>
> Key: SOLR-17971
> URL: https://issues.apache.org/jira/browse/SOLR-17971
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 9.0
> Reporter: Pierre Salagnac
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Internally, the {{REBALANCELEADERS}} command checks the results of leader
> re-assignment requests by looking at overseer result distributed maps.
> This is done in {{{}RebalanceLeaders.waitAsyncRequests(){}}}.
> When the cluster is configured to run distributed cluster processing (no
> overseer), results of leader re-assignment commands are not stored in these
> map. This makes the parent {{REBALANCELEADERS}} to wait for a long time and
> eventually timeout. Then it continues processing.
> That's unclear to me how the commands actually worked, but it seems leaders
> were correctly rebalanced even in case of a timeout. So there is no big
> functional impact.
> Instead of checking the overseer result maps, the parent command should check
> the requests status by invoking {{REQUESTSTATUS}} for each asynchronous ID.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
