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:
requestDispatcher/requestParsers/@multipartUploadLimitInKB
requestDispatcher/requestParsers/@enableRemoteStreaming
requestDispatcher/@handleSelect
abortOnConfigurationError
ryan
