lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
Date Wed, 16 Dec 2009 20:02:18 GMT


Mark Miller commented on SOLR-1277:

bq. maybe this is already in the spec

Nothing is completely nailed down in the spec - Yonik has done a bunch of work on the SolrCloud
page, but a lot of that is: we could do this, or we could do that, or we might do this. We
haven't really nailed much down firmly. Still pretty high level at the moment.

bq. How are we addressing a failed connection to a slave server, and instead of failing the
request, re-making the request to an adjacent slave?

We haven't really gotten there. But we want to cover that. What do you propose?

The more we get these discussions going, the faster things will start getting nailed down

bq. A failure is a failure and whether it's the GC or something else, it's really the same

Its kind of arbitrary distinctions. Your saying, we would say a GC pause of 4 seconds (under
the ZK client timeout) is not a failure, and a GC timeout of 6 seconds (over the ZK client
timeout) is a failure. I'm not claiming any distinction is better than another though - just
trying to work out the directions we want to go so I can start paddling.

I can code till the cows come home with no input, but you might not like the results :)

> Implement a Solr specific naming service (using Zookeeper)
> ----------------------------------------------------------
>                 Key: SOLR-1277
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>    Affects Versions: 1.4
>            Reporter: Jason Rutherglen
>            Assignee: Grant Ingersoll
>            Priority: Minor
>             Fix For: 1.5
>         Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch,
SOLR-1277.patch, zookeeper-3.2.1.jar
>   Original Estimate: 672h
>  Remaining Estimate: 672h
> The goal is to give Solr server clusters self-healing attributes
> where if a server fails, indexing and searching don't stop and
> all of the partitions remain searchable. For configuration, the
> ability to centrally deploy a new configuration without servers
> going offline.
> We can start with basic failover and start from there?
> Features:
> * Automatic failover (i.e. when a server fails, clients stop
> trying to index to or search it)
> * Centralized configuration management (i.e. new solrconfig.xml
> or schema.xml propagates to a live Solr cluster)
> * Optionally allow shards of a partition to be moved to another
> server (i.e. if a server gets hot, move the hot segments out to
> cooler servers). Ideally we'd have a way to detect hot segments
> and move them seamlessly. With NRT this becomes somewhat more
> difficult but not impossible?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message