jira at apache
Jul 10, 2012, 3:16 PM
Post #3 of 5
[ https://issues.apache.org/jira/browse/SOLR-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410991#comment-13410991 ]
[jira] [Commented] (SOLR-3591) Startup error not reflected in Solr web view
[In reply to]
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.
> 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 [at] lucene
For additional commands, e-mail: dev-help [at] lucene