[
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785295#action_12785295
]
Mark Miller edited comment on SOLR-1277 at 12/3/09 12:53 PM:
-------------------------------------------------------------
These system properties are actually already bugging me. They are essentially
for the case of a single core - in general, many of them won't work in the
multicore case, because you will want to be able to specify different values
for different cores - thats fine, this can be done in solr.xml. But its
annoying to have the two different mechanisms.
I've been thinking about the idea of perhaps "deprecating" the old single core
mode and requiring a solr.xml? One of the major changes would be the URLs and
directory structure - but it seems like we could allow a core with a name of
"", that has the same dir structure as single core now? Then the only real
change would be having solr.xml for many. We could leave the old support for no
solr.xml, but require it for new features like ZooKeeper integration.
That allows us to add whatever properties we need in a more simple manner. For
example, it might be nice if local config files would override zookeeper config
files - but I'd really like to make that optional. But I wouldn't want to add
another sys property for it, and then also support it in solr.xml per core.
was (Author: markrmil...@gmail.com):
These system properties are actually already bugging me. The are
essentially for the case of a single core - in general, many of them won't work
in the multicore case, because you will want to be able to specify different
values for different cores - thats fine, this can be done in solr.xml. But its
annoying to have the two different mechanisms.
I've been thinking about the idea of perhaps "deprecating" the old single core
mode and requiring a solr.xml? One of the major changes would be the URLs and
directory structure - but it seems like we could allow a core with a name of
"", that has the same dir structure as single core now? Then the only real
change would be having solr.xml for many. We could leave the old support for no
solr.xml, but require it for new features like ZooKeeper integration.
That allows us to add whatever properties we need in a more simple manner. For
example, it might be nice if local config files would override zookeeper config
files - but I'd really like to make that optional. But I would want to add
another sys property for it, and then also support it in solr.xml per core.
> 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.
