lucene-dev mailing list archives

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


Yonik Seeley commented on SOLR-1306:

At first blush, this seems to go in the wrong direction.
Rather than keep meta-data about a core/directory further away from the actual index for that
directory, it seems like we should move it closer (i.e. the meta-data for collection1 should
be kept under the collection1 directory or even the collection1/data directory).

Wouldn't it be nice to be able to back up a collection/shard by simply copying a single directory?
This applies to cloud too - it seems like info about the shard / collection the index belongs
to should ride around next to the index.
One should be able to bring down two solr servers, move a directory from one server to another,
then start back up and have everything just work.

> 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