jira at apache
Jul 10, 2012, 3:16 PM
Post #3 of 5
(76 views)
Permalink
|
|
[jira] [Commented] (SOLR-3591) Startup error not reflected in Solr web view
[In reply to]
|
|
[ 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 [at] lucene
For additional commands, e-mail: dev-help [at] lucene
|
