Return-Path: 
 <dev-return-113093-apmail-lucene-dev-archive=lucene.apache.org@lucene.apache.org>
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 9A2C5D14C
	for <apmail-lucene-dev-archive@www.apache.org>;
 Mon, 29 Oct 2012 12:16:19 +0000 (UTC)
Received: (qmail 7839 invoked by uid 500); 29 Oct 2012 12:16:17 -0000
Delivered-To: apmail-lucene-dev-archive@lucene.apache.org
Received: (qmail 7211 invoked by uid 500); 29 Oct 2012 12:16:16 -0000
Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:dev@lucene.apache.org>
List-Id: <dev.lucene.apache.org>
Reply-To: dev@lucene.apache.org
Delivered-To: mailing list dev@lucene.apache.org
Received: (qmail 6987 invoked by uid 99); 29 Oct 2012 12:16:15 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2012 12:16:15 +0000
Date: Mon, 29 Oct 2012 12:16:15 +0000 (UTC)
From: "Erick Erickson (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <1685265710.38720.1351512975205.JavaMail.jiratomcat@arcas>
In-Reply-To: <284904722.38625.1351509073314.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (SOLR-4011) SolrCore - correct behavior while
 having error loading specific cores
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-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485983#comment-13485983 ] 

Erick Erickson commented on SOLR-4011:
--------------------------------------

I'm not at all sure we _should_ fix this. In the vast majority of cases, just continuing would lead to hard-to-understand behavior. Imagine an innocent typo on a core definition line in the non-puppet (or other "special") setup for just one of your cores. Now you have users who can't find a document, but only when searching for that core, but you don't know why. The "fail fast" option makes that obvious when you start solr, not after you've deployed it to your production system and have customers complaining....

You can actually fire up a Solr with _no_ cores defined, and then use the "CREATE" command after you're sure the relevant file structure is in place. If you combine that with "persist=true" in your solr.xml file, you're in a situation where after you've deployed all your infrastructure and issued the proper "CREATE" commands, you'll have the setup in persisted to your solr.xml file. Despite its name, CREATE can be used as though it were something like OPEN or LOAD on a pre-existing collection.

In the future, could you raise this kind of question on the user's list first rather than opening a JIRA? We try to keep JIRAs for confirmed bugs...

Best
Erick


                
> SolrCore - correct behavior while having error loading specific cores
> ---------------------------------------------------------------------
>
>                 Key: SOLR-4011
>                 URL: https://issues.apache.org/jira/browse/SOLR-4011
>             Project: Solr
>          Issue Type: Improvement
>          Components: multicore
>         Environment: RHEL 6.1/6.3
> Solr 3.6.1
>            Reporter: Gianluca Varisco
>            Priority: Minor
>
> I've a multicore setup.  Solr.xml contains the following:
> <solr persistent="false">
>   <!--
>   adminPath: RequestHandler path to manage cores.  
>     If 'null' (or absent), cores will not be manageable via request handler
>   -->
> <cores adminPath="/admin/cores">
> <core name="a" instanceDir="/shop/www/htdocs/a/shop.staging/solr/app" dataDir="/shop/solr/staging/a/data/" configName="solrconfig.xml" schemaName="schema.xml" />
> <core name="b" instanceDir="/shop/www/htdocs/b/shop.staging/solr/app" dataDir="/shop/solr/staging/b/data/" configName="solrconfig.xml" schemaName="schema.xml" />
> <core name="c" instanceDir="/shop/www/htdocs/c/shop.staging/solr/app" dataDir="/shop/solr/staging/c/data/" configName="solrconfig.xml" schemaName="schema.xml" />
> </cores>
> </solr>
> When solr starts, it tries to LOAD all the cores. If one fails (no solrconfig.xml or instanceDir found), the whole multicore configuration is broken and Solr won't answer as well for the other two cores. 
> Is there a workaround for it? Reasons while it can happen is, for example, if cores' creation in the XML are managed indipendently (e.g via Puppet) but applications are not deployed in that instanceDir yet (therefore: no solrconfig.xml/schema.xml). Is there a specific parameter to use?
>  

--
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