[jira] [Commented] (SOLR-7199) core loading should succeed irrespective of errors in loading certain components

["Hoss Man (JIRA)" <ji...@apache.org>]

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