Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <204466959.2331267513647108.JavaMail.jira@brutus.apache.org>
Date: Tue, 2 Mar 2010 07:07:27 +0000 (UTC)
From: "Hoss Man (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Commented: (SOLR-1743) error reporting is rendering "404
 missing core name in path" for all type of errors
In-Reply-To: <1650884589.5591265022710848.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hoss Man commented on SOLR-1743:
--------------------------------

Okay now i'm just going to rant...

abortOnConfigurationError feels like it's just devolved into nonsense at this point .. the orriginal purpose was to let people configure wether they wanted to solr to try to keep running even if something like a request handler couldn't be loaded -- set it to true and solr wouldn't start up and the admin screen would tell you why, set it to false and solr would work, but requests for that request handler would fail

once we added multicore support, the usage of abortOnConfigurationError just stoped making sense ... if your solr.xml refers to just core1, and core1's solrconfig.xml sets it to "false" and has a request handler that can't be llooaded things keep working -- but if you also have a core2 whose solrconfig.xml sets it to "true" then the whole server won't start up ... that's just silly.

Maybe it's just time to rethink the whole damn thing...
* deprecate the SolrConfig.SEVERE_ERRORS singleton - make SolrCore start keeping a personal list of exceptions it was able to get past (ie: a plugin it couldn't load)
* Eliminate Initializer.isAbortOnConfigurationError - instead make each SolreCore keep track of that itself
* if initializing a core throws an exception (either from parsing the config, or from instantiating the SolrCore or IndexSchema) CoreContainer should keep track of that exception as being specific to that core name (Map<String,Exception>)
** removing a core, or recreating a core with the same name should clear any corresponding entry from this map
* when SolrDispatchFilter processes a path, it should generate a useful error message in either case:
** CoreContainer says it has an init exception for the core name that corresponds to that path
** the SolrCore exists; has sAbortOnConfigurationError()=true; and has a non-empty list of exceptions


...thoughts?

> error reporting is rendering "404 missing core name in path" for all type of errors
> -----------------------------------------------------------------------------------
>
>                 Key: SOLR-1743
>                 URL: https://issues.apache.org/jira/browse/SOLR-1743
>             Project: Solr
>          Issue Type: Bug
>          Components: Build
>         Environment: all
>            Reporter: Marcin
>            Assignee: Mark Miller
>             Fix For: 1.5
>
>         Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch
>
>
> despite the error in schema syntax or any other type of error you will always get:
> "404 missing core name in path" communicate.
> cheers,
> /Marcin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.