lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
Date Sat, 12 Dec 2009 23:47:18 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789822#action_12789822
] 

Mark Miller edited comment on SOLR-1277 at 12/12/09 11:46 PM:
--------------------------------------------------------------

Ok, continued being a rude host and looked right now ;)

Yeah, the ref in the core is currently just a convenience. The client belongs to the CoreContainer
though. Most of this code is pretty exploratory. Thats why I put the //nocommit above the
getZooKeeper method on core - that all has to be considered. Of course you can just use the
coreDescriptor to get the corecontainer, and then get the ZooKeeper component. But just for
ease right now, the core is holding its own ref - not its own client though.

*edit*

Though at a minimum, it doesn't make sense to keep the overloaded constructors as is - even
if the core is to keep its own ref (which is not necessary, just saves a couple method calls),
it would make more sense to pull it off the coredescriptor.getCoreContainer. I just patched
that all in real quick at the beginning - currently nothing even uses it. I just put it there
real quick when I was considering how component and handlers would access the ZooKeeper component.

      was (Author: markrmiller@gmail.com):
    Ok, continued being a rude host and looked right now ;)

Yeah, the ref in the core is currently just a convenience. The client belongs to the CoreContainer
though. Most of this code is pretty exploratory. Thats why I put the //nocommit above the
getZooKeeper method on core - that all has to be considered. Of course you can just use the
coreDescriptor to get the corecontainer, and then get the ZooKeeper component. But just for
ease right now, the core is holding its own ref - not its own client though.
  
> 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,
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.


Mime
View raw message