lucene-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-3591) Startup error not reflected in Solr web view
Date Tue, 10 Jul 2012 22:16:35 GMT

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

Hoss Man commented on SOLR-3591:
--------------------------------

It sounds like there are two related problems that compound int oa really bad experience...

----

*1) the web ui isn't cleaning dealing with the situation where there are "no cores" returned
by the CoreAdminHandler.*

this is a legitimate situation, that doesn't neccessarily indicate an error.  

if there are no cores, then the ui shouldn't blindly try to load "/solr/null/admin/system?wt=json"
and then complain that the admin handler can't be found -- the logic should be something like:

* can we talk to CoreAdminHandler at all? if not give a specific error
* if CoreAdminHandler says there are no cores, give a message to that effect 
** offer the info/commands that are stil available (ie: "Core Admin" functionality)
** perhaps suggesting that if they expected to cores to already exist, they should check logs
9allthough this may not be needed depending on how far we get with "#2" below)
* if cores are available, then try to use /corename/admin to get the other info to populate
the UI, and if we can't find it *then* mention that they need to add config
** i would also suggest using the "defaultcore" if non-null instead of just whatever core
happens to be listed first (but that's a good fallback if there is no default core)

----

*2) no external reporting of errors in initializing cores*

once upon a time, Solr had an "abortOnConfigurationError" option per core, that never really
worked well, and would try to partially initialize a core even if some things failed.  In
conjunction with that (broken) setting, was a static list of Exceptions that had been thrown
during SolrCore construction, which the SolrRequestDispatcher would try to use to generate
an error messages if there was a problem.

All of that code has been ripped out of trunk for a long while, largely because it didn't
work, and it _REALLY_ didn't work well with multicore, but as erik points out the one thing
that it _did_ help with was in making it obvious when there were config problems on startup.

I think we should at least partially revive the idea of keeping track of the list of "severe"
errors, but there are a lot of things we can do differnetly now:

* instead of being static, it can be managed by the CoreContainer
* it can specificly be exceptions caught by CoreContainer while initializing SolrCores.
* we can maintain it as a map of (String)coreName -> Pair<(Date)timstamp,(Exception)error>
so it's clear what exception came from initializing which solr core
** by using a name mapping, we can delete entires if/when a SolrCore is re-loaded to fix the
error.
* we can return this map in CoreAdminHandler so the UI can display a big flashing warning
about cores that failed to initialize (both on startup, or if some remote command tried to
create a core programaticly)

----

i suggest we spin off a new Jira for #1 since that is somewhat independent (we need to change
the "no cores" behavior of the UI no matter what else we do) and use sub-tasks of this issue
to track improvements to CoreContainer/CoreAdminHandler/UI to display errors related to SolrCore
initialization.

sound good?
                
> Startup error not reflected in Solr web view
> --------------------------------------------
>
>                 Key: SOLR-3591
>                 URL: https://issues.apache.org/jira/browse/SOLR-3591
>             Project: Solr
>          Issue Type: Bug
>          Components: web gui
>    Affects Versions: 4.0-ALPHA
>            Reporter: Erik Hatcher
>            Assignee: Stefan Matheis (steffkes)
>            Priority: Blocker
>             Fix For: 4.0
>
>         Attachments: screenshot-1.jpg
>
>
> When Solr has a fatal startup error, it used to be reflected in general responses from
Solr.  With the new UI, it's relegated to only the logs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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


Mime
View raw message