lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
Date Wed, 17 Mar 2010 00:15:27 GMT


Hoss Man commented on SOLR-1817:

bq. this is part of the big open issue I think is left here - how to properly deal with abortOnServerConfError.

Here's what i think makes the most sense in a multi-core world, and is the most in the "spirit"
of what that options was ment to do when it was added for single cores.

a) SolrCore should itself maintain a list of "Severe Initialization Exceptions" that it was
able to "get passed" when initializing itself. specificly: when a plugin could not be initialized,
and it therefore is ignoring that plugin declaration.

b) SolrCore should expose an easy way of asking it for it's list of initialization exceptions

c) SolrCore should pay attention to wether it's solrconfig.xml file indicats if the core should
be usable if there were severe initialization exceptions.

d) SolrCore should refuse to "execute" any requests if (a) contains Exceptions and (c) is

e) SolrCore should throw any exceptions it can't "get passed"

f) CoreContainer should keep track of which core names completely failed to initialize, and
what exception was encountered while trying (ie: Map<SolrCore,Throwable> ... no List
needed).  This should be the first exception involved -- even if it came from trying to instantiate
the IndexSchema, or parse the solrcofig.xml file before it ever got to the SolrCore.  CoreContainer
shouldn't know/care about (a) or (c)

g) CoreContainer should provide an easy way to query for (f) by core name

h) If SolrDispatchFilter asks CoreContainer for a corename, and no SolrCore is found with
that name, it should then use (g) to generate an error message

i) SolrDispatchFilter shouldn't know/care about (a) or (c) ... it should just ask SolrCore
to execute a request, and SolrCore should fail as needed based on it's settings (this will
potentially allow things like SOLR-141 to work even with init errors, as long as the ResponseWriter
was initialized successfully)

j) SolrConfig.severeErrors should be deprecated, but for back-compat SolrCore and CoreContainer
can add to it whenever they add an exception to their own internal state.

k) CoreContainer.Initializer.*AbortOnConfigurationError should be deprecated, but can still
continue to provide the same behavior they do on the trunk (ie: influence the "default" value
for each core prior to init, and return true if any of the cores have a value of "true" for
that property after init)

l) we could concievable make solr.xml have it's own "abortOnConfigError" type property, but
frankly i think if there are *any* errors in solr.xml, that should just be a stop the world
type situation, where  CoreContainer.Initializer.initialize() just throws a big fat error
and CoreContainer deals with it ... i can't think of any good that could possibly come from
letting solr proceed when it encounteres an error in solr.xml

> Fix Solr error reporting to work correctly with multicore
> ---------------------------------------------------------
>                 Key: SOLR-1817
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: Mark Miller
>            Priority: Minor
>             Fix For: 1.5
>         Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch
> Here is a rough patch that attempts to fix how error reporting works with multi-core
(not in terms of logs, but what you see on an http request).
> The patch is not done - more to consider and havn't worked with how this changes solrconfigs
abortOnConfigurationError, but the basics are here.
> If you attempt to access the path of a core that could not load, you are shown the errors
that kept the core from properly loading.

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

View raw message