lucene-dev mailing list archives

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


Mark Miller commented on SOLR-2765:

{quote}to do something like this though we'd need to have some leader which was responsible
for maintaining this state. Wouldn't this still result in a large amount of data being pulled
by the searchers for a very small change (i.e. 1 additional searcher being added). {quote}

Or, assuming state changes are infrequent, you just use optimistic locking and retries? Or
a state lock (though you probably want to avoid global locks if you can, I'm less worried
about that for something that will generally be stable I guess)? Even if the whole state was
an in XML file, I'm guessing it would be plenty faster though ... I would guess the real issue
is the request per node. I'd guess the description of a large cluster in one request would
be much faster than reading  a bit of data on 500 nodes.
> 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, scheduled_executors.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