lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <>
Subject Re: purpose of MultiCore "default" ?
Date Wed, 19 Dec 2007 23:01:15 GMT
Henrib wrote:
> Indeed, I reworded (plagiarized) your original proposal; sorry it took me a
> full thread loop to grasp it & realize that...
> About "comfort", it feels like having one name and multiple aliases per core
> would be "easier" to work with than using a path-based identification; since
> the path is dependent on the deployment host (path can even be dependent on
> an environment variable), using a logical name would preserve more
> genericity (replication for instance).
> On that premise, there are a few restrictions that {sh,c}ould apply:
> 0 - Name and aliases reside in a common identifier space; one identifier
> uniquely determines a core (can't have the identifier 'core' used a a name
> to point to coreA and as an alias to point to coreB)
> 1 - One core has one unique immutable name
> 2 - One core may have many aliases
> 3 - There are only 2 admin commands related to aliases:
>    3.1 - alias(core, alias): adds an alias to a core, overriding any
> existing alias but fails to override a core name.
>    3.2 - unalias(str); if str is a core name identifier, all its aliases get
> deleted, if str is an alias identifer only that alias gets deleted.
> 4 - Core addressing through URLs/API can use either name or alias (although
> using alias is best practice for common -aka non-admin- operations)
> Would this still fit the bill? Any obvious (or not so) show-stopper?
> I'll try to post a prototype later to see how it goes.

implementation wise, things get a little dicy when we allow multiple 
names for a core.

Going back to the problem default/alias is trying to solve:  I want to 
"re-index" a core and have clients continue to use it transparently.  As 
mentionied RENAME does not work because you loose access to a core that 
needs to be unloaded, but we could have a command for SWAP (or somehting 
like that).  This way when you want to reload a core you:

1. public queries "mainCore"
2. LOAD("tempCore") with same configs as "mainCore"
3. send all <add> commands to "tempCore"
5. SWAP("mainCore","tempCore") -- a synchronized name swap
6. UNLOAD("tempCore")

this would avoid having to manage/serialize multiple names.

That leaves one purpose of MultiCore "default" -- there may be a better 
solution for it:  the "default" core is used to set the web-app wide 
variables configured in solrconfig.xml:


View raw message