[
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784940#action_12784940
]
Brian Pinkerton commented on SOLR-1277:
---------------------------------------
Yes, we'll definitely want to have different timeouts. For instance, I can see
having the indexer have a relatively long timeout, while query slaves would
have very short timeouts.
Patrick, how low is it feasible to set the timeout? Could it be set low enough
that it could be the only input to a failover decision in the case of a very
high query load? That is, say a cluster with 3 query slaves is handling 600
queries per second, which means each is getting 200qps, or one every 5ms on
average. If a slave were to fail, queries will start backing up pretty quickly
unless a decision is made to drop the failed node within 500ms or so. Clearly,
whatever node is distributing the queries to the slaves can make the failed
node down (say, in the case of a HW load balancer), but could we rely on ZK to
handle this for us?
> Implement a Solr specific naming service (using Zookeeper)
> ----------------------------------------------------------
>
> Key: SOLR-1277
> URL: https://issues.apache.org/jira/browse/SOLR-1277
> 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, 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.
