[
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741878#action_12741878
]
Grant Ingersoll commented on SOLR-1277:
---------------------------------------
bq. The same information is repeated in the name
Ideally, the name would contain all the info and you wouldn't have to use the
data bit here at all, but the Solr URL also looks like a ZK path, so I escaped
the string for the name and also stored it on the data. Of course, the name
could be anything, but I thought it should at least be something that is going
to be human readable.
bq. If there are multiple cores which zkrequesthandler will be used?
It's configured in Solr Config, so whichever core does the configuration. I
suppose this requires you to pick a core that has the Req Handler, but the
ZooKeeper client is lightweight, so it isn't a big deal if there are multiple
Req Handlers having one. So, just configure it on every core if you want. I
believe the current impl is that the ZooKeeper is attached to the SolrCore, so
I think it should just work, but I haven't tested it.
> 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, zookeeper-3.2.0.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.
