Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A2528D1EC for ; Wed, 14 Nov 2012 13:22:16 +0000 (UTC) Received: (qmail 80454 invoked by uid 500); 14 Nov 2012 13:22:14 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 80259 invoked by uid 500); 14 Nov 2012 13:22:14 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 80233 invoked by uid 99); 14 Nov 2012 13:22:14 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Nov 2012 13:22:14 +0000 Date: Wed, 14 Nov 2012 13:22:13 +0000 (UTC) From: "Noble Paul (JIRA)" To: dev@lucene.apache.org Message-ID: <1050887578.113712.1352899334050.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (SOLR-1306) Support pluggable persistence/loading of solr.xml details MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/SOLR-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497083#comment-13497083 ] Noble Paul commented on SOLR-1306: ---------------------------------- Yes you are right the custom implementation should take care of walking the tree and identifying the cores. But at the same time we have to keep in mind that deletion of cores will not just happen immediately as as I fire the command. The actual cleanup of the file systems will happen a bit later. So we should have some kind of a marker to say that if that core is actually a live one. IMHO As much as possible we should avoid completely pluggable solutions , because we clearly know that there are only a couple of scenarios. > 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} > > > > {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