lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Dunning (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-2765) Shard/Node states
Date Sun, 09 Oct 2011 20:29:29 GMT


Ted Dunning commented on SOLR-2765:

So in my mind I am not sure why we need the /collections instance anymore. If we maintain
the state of the cluster in /cloudstate but don't remove the nodes that have gone down (as
Mark mentioned) and just update their status, it seems like we should be able to do what we
As I mentioned in the (too long) comment, these have to be removed in order to get an accurate
view of current state.  If we _really_ want to have a slightly historical view, marking replicas
as defunct might do, but as things move around you will just get a muddle.  I think it is
better to leave cloudstate with state as it is now and collections as state as it should be.
 For history, go to the logs.

Btw... in English, we are consistently saying "cluster state", but the file is called "cloudstate".
 There seems a contradiction here that is easily remedied.

> Shard/Node states
> -----------------
>                 Key: SOLR-2765
>                 URL:
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud, update
>            Reporter: Yonik Seeley
>             Fix For: 4.0
>         Attachments: combined.patch, incremental_update.patch, scheduled_executors.patch,
> Need state for shards that indicate they are recovering, active/enabled, or disabled.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


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

View raw message