lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <>
Subject [jira] [Commented] (SOLR-1306) Support pluggable persistence/loading of solr.xml details
Date Thu, 15 Nov 2012 14:14:12 GMT


Erick Erickson commented on SOLR-1306:

The use-case has come up on the list for quite a while. Multi-tenant situations that are sparsely
used, where the necessary balancing of tenants to machines is carried out by physically moving
cores around different machines as usage patterns/core sized change. FWIW, this is not theoretical.

And I'm not sure what the complexity issue is. _Most_ of the actual code changes in SOLR-1028
are all about making it possible to lazily load cores and they're more organizational (extracted
a couple of methods that kinda makes the diff output look way more scary than it is).

But I'll tell you what. I'll sweeten the pot with
to back up my claim that this work makes nuking solr.xml easier.
> Support pluggable persistence/loading of solr.xml details
> ---------------------------------------------------------
>                 Key: SOLR-1306
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: multicore
>            Reporter: Noble Paul
>            Assignee: Erick Erickson
>             Fix For: 4.1
>         Attachments: SOLR-1306.patch, SOLR-1306.patch, SOLR-1306.patch, SOLR-1306.patch
> Persisting and loading details from one xml is fine if the no:of cores are small and
the no:of cores are few/fixed . If there are 10's of thousands of cores in a single box adding
a new core (with persistent=true) becomes very expensive because every core creation has to
write this huge xml. 
> Moreover , there is a good chance that the file gets corrupted and all the cores become
unusable . In that case I would prefer it to be stored in a centralized DB which is backed
up/replicated and all the information is available in a centralized location. 
> We may need to refactor CoreContainer to have a pluggable implementation which can load/persist
the details . The default implementation should write/read from/to solr.xml . And the class
should be pluggable as follows in solr.xml
> {code:xml}
> <solr>
>   <dataProvider class="" attr1="val1" attr2="val2"/>
> </solr>
> {code}
> There will be a new interface (or abstract class ) called SolrDataProvider which this
class must implement

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message