Chris Hostetter wrote:
Forgive me if i'm off base with some stuff here ... i'm still trying to
wrap my head arround some of the new multicore stuff.
No forgiveness here! The more comments/questions/clarification, the
better for everyone. Especially for something as substantial as this.
1. start up server with a single "core0" as default
2. use default URLs all day long...
GET http://localhost:8983/solr/select?q=bar
POST http://localhost:8983/solr/update ...
GET http://localhost:8983/solr/select?q=foo
3. decide you want to change the schema or something,
load a new "core0"
4. rebuild your index using "core0" urls...
POST http://localhost:8983/solr/@core1/update ...
5. once you're happy with "core1", set it as the default,
and unload core0...
GET
http://localhost:8983/solr/admin/multicore?action=SETASDEFAULT&core=core1
GET
http://localhost:8983/solr/admin/multicore?action=UNLOAD&core=core0
6. keep using core1 just like you use to use core0 with
default urls...
GET http://localhost:8983/solr/select?q=bar
POST http://localhost:8983/solr/update ...
GET http://localhost:8983/solr/select?q=foo
Yes, this is exactly what I had in mind. I want to periodically rebuild
an index without downtime and without mucking with a load balancer.
...this seems like a really cool use case of multicores, but it also
seems like it is incompartible with the primary goal of multicores:
having lots of different indexes; afterall: there's only one default, so
you can only use this trick with one of your indexes.
I have seen the primary goal of multicore as allowing you to modify /
reload a core at runtime. The static singletons prohibited any changes
after startup.
It seems like if this is the only "perk" or having a "default" core, it
would make more sense to require a core name in every url (when
multicore support is turned on) and replace the SETASDEFAULT operation
with a RENAME operation that changes the name of a core (unloading any
previous core that was using that name) ... or maybe even support
multiple names per core, with some ADDNAME, REMOVENAME, and MOVENAME
options...
1 /admin/multicore?action=ADDNAME&coreDir=cores/dir0&name=yak
2 /@yak/select?q=*:*
3 /admin/multicore?action=ADDNAME&coreDir=cores/dir1&name=foo
4 /@foo/select?q=*:*
5 /admin/multicore?action=ADDNAME&coreDir=cores/dir1&name=bar
6 /@bar/select?q=*:*
(#4 and #6 are now equivilent)
7 /admin/multicore?action=REMOVENAME&coreDir=cores/dir1&name=foo
(now #4 no longer works)
8 /admin/multicore?action=MOVENAME&coreDir=cores/dir0&name=bar
(now #2 and #6 are equivilent)
thoughts?
I think we should keep LOAD,UNLOAD,RELOAD and then adding "RENAME"
I am fine with this. The only problem I have is that solrj clients
would need to be configured with the solr url AND the default core name
rather then just the solr url.
This would make the multi-core URL rule:
http://host/context/corename/handler?params
The only naming restraint is that "corename" can not contain '/'
(handler can contain '/')
ryan
