[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
