[
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785397#action_12785397
]
Mark Miller commented on SOLR-1277:
-----------------------------------
bq. Yep, me too. That doesn't necessarily make solr.xml required though.
Right, as I said above, I don't think so either - we could have a dummy simple
solr.xml that would be used if you don't want to customize anything (pull from
the jar or a String, or whatever) - that would allow for the same code paths in
either case.
bq. It would also be very nice if we could avoid breaking all of the existing
URLs by having a core that could also act as a default core or something. IIRC
this was discussed in the past - not sure what the outcome was though.
Thats essentially the change I'm talking about - though I think in a different
way. You can do that now by just adding an alias for a core with a name of "".
We don't do it out of the box now - don't remember exactly why either, but I
think Hoss ended up putting the kibosh on it for various reasons.
What I'm suggesting here is a little different though - that Solr.xml allows a
core config that acts like single core now - a core name of "" and an instance
dir of "" or "." that sets everything to work as single core now. That simple
config would be the "dummy" Solr.xml that we load when we don't find one. It
also lets a multicore user setup whatever cores he wants, plus still have a
core that acts as single core does now in terms of URLs, config. Its a fairly
simple change too.
Then we can say, okay, you can use single core with no solr.xml, but if you
want to use zookeeper with singlecore, add the solr.xml and setup the required
config - but you don't have to switch to the multicore structure - it would be
a seamless change.
> 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.
