lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
Date Tue, 16 Mar 2010 18:40:27 GMT

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

Hoss Man commented on SOLR-1817:
--------------------------------

Hey mark: i've only had a chance to skim your patch so far, and i'm still not sure if i have
jury duty today, so i don't know if i'll have any time to really test it out this afternoon,
but here are my quick impressions (mixed with my thoughts on how to do this before i saw your
patch):

1) fundementally we have two differnet kinds of initialization exceptions -- the ones SolrCore
can deal with and keep going, and the ones that are complete show stoppers. Regardless of
what the "abortOnServerCOnfError" configuration looks like, it seems like these exceptions
should be tracked separately.  We should let SolrCore catch and keep track of any exceptions
that it can "ignore" while still providing functionality; but if anything it can't deal with
occurs it should just throw it and then let caller (ie: CoreContainer) keep track of it. 


That way SOlrCore (and the errors it's tracking) are still usable by embedded users who may
not even be using coreContainer (i think there's an NPE possibility there in your current
patch ... if people construct a SolrCore without a CoreDescriptor)

2) It looks like you still have SolrDispatchFilter looking at SolrConfig.severeErrors.  It
seems like the logic there should be something like...

{code}
SolrCore core = coreContainer.getCoreNyName(corepath)
if (null == core) {
  Throwable err = coreContainer.getCoreInitError(corepath)
  if (null == err) {
    write_init_errors_for_core(corepath, err)
  }
}
if (core.abortOnConfigError() && 0 < core.getSevereErrors().size()) {
   write_init_errors_for_core(corepath, err)
}
{code}

3) we should think about how the no-arg behavior of the CoreAdminHandler should deal with
reporting about cores that couldn't be initialized

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


Mime
View raw message