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 Fri, 07 Oct 2011 22:16:30 GMT


Ted Dunning commented on SOLR-2765:

I don't think that you need all nodes to watch all nodes.

What you need is a directory of assigned states that a central overseer sets.  Each node will
watch their assignment to see which shards to serve and what state to assume.

Then you need the live_nodes directory where all nodes can advertise an ephemeral showing
their current status including which shards served and any other information.  Since this
is SOLR, XML is a natural format for that.

The only watcher on the live_nodes directory and the node files in that directory is the overseer.

If a node dies, ZK will send notifications to all live query connections and the overseer.

It is also nice to have the current serving state for query connections to be in a file or
in  directory form.  This file could be updated (atomically) by nodes as they start or stop
serving shards, but would have to be updated by the overseer on node failure.  Using a per
shard directory allows the list of nodes serving a shard to be handled as ephemerals, but
it is a bit less desirable because zknode names have to contain node references which is an
example of name/content confusion.  Since atomic update is easy in ZK, the file implementation
is probably better.

The update to current shard state will ultimately cause a notification to be sent to each
live query connection.

> Shard/Node states
> -----------------
>                 Key: SOLR-2765
>                 URL:
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud, update
>            Reporter: Yonik Seeley
>             Fix For: 4.0
>         Attachments: incremental_update.patch, shard-roles.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