lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-1306) Support pluggable persistence/loading of solr.xml details
Date Wed, 14 Nov 2012 14:16:12 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497114#comment-13497114
] 

Mark Miller commented on SOLR-1306:
-----------------------------------

You must have a solr home for each core anyway - I'm not sure the advantage of having this
open ended pluggable point here. Keeping this simple and just doing solrhome auto discovery
(with the ability to add multiple root folders to look in) just seems much simpler. I'm not
convinced there are use cases that are worth the cost of making all this pluggable?


                
> Support pluggable persistence/loading of solr.xml details
> ---------------------------------------------------------
>
>                 Key: SOLR-1306
>                 URL: https://issues.apache.org/jira/browse/SOLR-1306
>             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="com.foo.FooDataProvider" 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: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message