[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846227#action_12846227
]
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 true
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: https://issues.apache.org/jira/browse/SOLR-1817
> 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.
