lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-11448) Implement an option in collection commands to wait for command results
Date Tue, 02 Jan 2018 18:35:00 GMT


David Smiley commented on SOLR-11448:


bq. and it's usually acceptable to user that the cluster state may still undergo changes as
replicas gradually recover and become active.

So long as such changes don't impact the apparent usability of the collection (ability to
search and add docs without error) then I agree, otherwise I don't.  If we don't then do you
mean _sometimes_ the user may not care?  Well that's what async is for; no?

It seems like a wart to see CollectionsHandler check that a collection creation is being performed
and then call a waitForActiveCollection... this is an exceptional case instead of being agnostic
of the command.  I think you'd see what I mean if you look over there in CollectionsHandler.
 Instead, I propose CreateCollectionCmd actually waits sufficiently long for the collection
to be usable at the point it returns (thus move this method over there).  Would it need a
new parameter to know when to *not* wait or does "async" imply as much?  But even in async
case... it might as well wait for things to complete so that if the async status is finally
done then the collection is truly usable.

> Implement an option in collection commands to wait for command results
> ----------------------------------------------------------------------
>                 Key: SOLR-11448
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message