[
https://issues.apache.org/jira/browse/SOLR-7199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363480#comment-14363480
]
Hoss Man commented on SOLR-7199:
--------------------------------
I got 1 line into this patch and it already scares the shit out of me...
{noformat}
- assertTrue(hasInitException("QueryElevationComponent"));
+ LocalSolrQueryRequest req = lrf.makeRequest("qt", "/elevate");
+ try {
+ h.query(req);
+ fail("Error expected");
+ } catch (Exception e) {
+ assertTrue(e.getMessage().contains("Error initializing plugin of
type"));
+ }
+
{noformat}
...so now, instead of a broken configuration giving a clera & monitorable
error, and the core preventing users from trying to do things while it's in a
broken state, the only way to know that a handler isn't available is to hit it
with a query and get a run time error from the request?
so if i have a dozen handlers, i have to query each one with a real query to
find out that they had an init error? this is a terrible idea.
Solr use to work this way, way way back in the day -- and it was terrible.
We worked REALLY hard to put pandora back in the box with SOLR-179. We should
not go back down this road again.
bq. In SolrCloud, the collection is totally gone and there is no way to
resurrect it using any commands .
this is not true -- in solr cloud, the user can fix the configs and do an
entire collection reload.
bq. If the core is loaded , I can at least use config commands to correct those
mistakes .
if an API broke the configs so that the core can't load and needs to be
"fixed", then we should harden those APIs so that they can't break the configs
-- the API request itself should fail. Alternatively: if there are other ways
things can fail, but we want config APIs to be available to fix them, then
those APIs should be (re)designed so that they can be used even if the core is
down.
bq. In short, Solr should try to make the best effort to make the core
available with whatever components available.
I strongly disagree -- you are assuming you know what is "best" for _all_ users
when they have already said "this is hte config i want to run" -- if Solr can't
run the config they have said they want to run, then Solr should fail fast and
hard.
the *ONLY* possible way i could remotely get on board with an idea like this
is if it wasn't the default behavior, and users had to go out of their way to
say "if this handler/component/plugin doesn't load, please be graceful and
still startup the rest of my plugins" ... and we already have a convention like
this with {{lazy="true"}} ... if you want to make more things support lazy=true
as an option, that's a decent idea worth discussing, but i'm a huge -1 to this
patch as written.
> core loading should succeed irrespective of errors in loading certain
> components
> --------------------------------------------------------------------------------
>
> Key: SOLR-7199
> URL: https://issues.apache.org/jira/browse/SOLR-7199
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Attachments: SOLR-7199.patch
>
>
> If a certain component has some error , the core fails to load completely.
> This was fine in standalone mode. We could always restart the node after
> making corrections. In SolrCloud, the collection is totally gone and there is
> no way to resurrect it using any commands . If the core is loaded , I can at
> least use config commands to correct those mistakes .
> In short, Solr should try to make the best effort to make the core available
> with whatever components available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
