lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-3591) Startup error not reflected in Solr web view
Date Tue, 10 Jul 2012 22:16:35 GMT


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

sound good?
> Startup error not reflected in Solr web view
> --------------------------------------------
>                 Key: SOLR-3591
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message