[
https://issues.apache.org/jira/browse/SOLR-11448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16308297#comment-16308297
]
Andrzej Bialecki commented on SOLR-11448:
------------------------------------------
bq. why wouldn't we always want to wait for final state (assuming this isn't an
async call)?
[~dsmiley] the purpose of the {{waitForFinalState}} flag is somewhat different
- it just ensures that all shards have leaders, OR that any replicas that were
being moved have indeed been moved successfully and became active. The reason
for this flag is to make sure the autoscaling actions leave collections in
stable state when they report success (or failure) - reporting success
prematurely, while some replicas are still recovering, would cause the
subsequent autoscaling actions to work with a cluster state that is bound to
change while the autoscaling plan is being computed (which itself may take
several seconds) - ultimately causing the newly computed plan to be either
invalid or suboptimal.
When collection commands are issued manually this timing is not so important -
in fact, defaulting to false allows the command to report success sooner, and
it's usually acceptable to user that the cluster state may still undergo
changes as replicas gradually recover and become active.
> Implement an option in collection commands to wait for command results
> ----------------------------------------------------------------------
>
> Key: SOLR-11448
> URL: https://issues.apache.org/jira/browse/SOLR-11448
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
> Affects Versions: 7.2
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11448.diff
>
>
> In order to reliably track results and impact of executing collection-level
> commands in the autoscaling framework we need an option to execute the
> requested operation (eg. move replica) and then wait for the operation
> results to actually take effect (the replica has been moved AND it became
> active).
> This is different than executing commands synchronously, in which case the
> API only waits for the operation itself to be completed (eg. moving the
> replica succeeded) but it does not wait for the final effects of this
> operation to take place (eg. the replica becomes active).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
