[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877544#comment-15877544 ] ASF subversion and git services commented on SOLR-10020: Commit f5ea2022097503df4ed62e59f7d1cb061c8266ee in lucene-solr's branch refs/heads/branch_6x from Erick [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f5ea202 ] SOLR-10020: CoreAdminHandler silently swallows some errors (cherry picked from commit 14b3622608d3312eca32ba749132ce2f8531326a) > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-10020.patch, SOLR-10020.patch, SOLR-10020.patch, > SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877538#comment-15877538 ] ASF subversion and git services commented on SOLR-10020: Commit 14b3622608d3312eca32ba749132ce2f8531326a in lucene-solr's branch refs/heads/master from Erick [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=14b3622 ] SOLR-10020: CoreAdminHandler silently swallows some errors > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-10020.patch, SOLR-10020.patch, SOLR-10020.patch, > SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[
https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876667#comment-15876667
]
Mike Drob commented on SOLR-10020:
--
Exactly. And because we don't start a new thread in the handler, we can throw
an exception which eventually gets back to the caller instead of solely logging
the problem.
LISTSNAPSHOTS_OP also throws an exception, so does not have this problem.
FORCEPREPAREFORLEADERSHIP_OP logs but does not throw, so a client will not see
the problem with a non-existent core. This is easy to fix with something like
{noformat}
core.getCoreDescriptor().getCloudDescriptor().setLastPublished(Replica.State.ACTIVE);
log().info("Setting the last published state for this core, {}, to {}",
core.getName(), Replica.State.ACTIVE);
} else {
-SolrException.log(log(), "Could not find core: " + cname);
+throw new SolrException(ErrorCode.BAD_REQUEST, "Unable to locate core
" + cname);
}
}
}),
{noformat}
I didn't do that in this patch because I'm not sure who the callers of this API
are and didn't want to rock too many boats at once.
> CoreAdminHandler silently swallows some errors
> --
>
> Key: SOLR-10020
> URL: https://issues.apache.org/jira/browse/SOLR-10020
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10020.patch, SOLR-10020.patch, SOLR-10020.patch
>
>
> With the setup on SOLR-10006, after removing some index files and starting
> that Solr instance I tried issuing a REQUESTRECOVERY command and it came back
> as a success even though nothing actually happened. When the core is
> accessed, a core init exception is returned by subsequent calls to getCore().
> There is no catch block after the try so no error is returned.
> Looking through the code I see several other commands that have a similar
> pattern:
> FORCEPREPAREFORLEADERSHIP_OP
> LISTSNAPSHOTS_OP
> getCoreStatus
> and perhaps others. getCore() can throw an exception, about the only explicit
> one it does throw is if the core has an initialization error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876626#comment-15876626 ] Erick Erickson commented on SOLR-10020: --- Mike: Just to check my understanding here. Essentially you took out a thread that had no other real purpose than to start a thread, right? We haven't changed the asynchronous nature of the call at all for RequestRecovery. Looking more closely at FORCEPREPAREFORLEADERSHIP_OP LISTSNAPSHOTS_OP I don't think the same problem occurs there since they don't spawn threads that can't really propagate the error back. Testing & etc now. > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-10020.patch, SOLR-10020.patch, SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876411#comment-15876411 ] Mike Drob commented on SOLR-10020: -- Yea, I think this one is ready. > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-10020.patch, SOLR-10020.patch, SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876405#comment-15876405 ] Erick Erickson commented on SOLR-10020: --- [~mdrob] Do you think this patch is ready to commit? If so I'll look it over again and commit it sometime Real Soon Now. Erick > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson > Attachments: SOLR-10020.patch, SOLR-10020.patch, SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15858409#comment-15858409 ] Erick Erickson commented on SOLR-10020: --- Had a chance to look and this looks fine. We now get a response that shows the FileNotFound error for the three commands I'd eyeballed. +1 and thanks! > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson > Attachments: SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856873#comment-15856873 ] Erick Erickson commented on SOLR-10020: --- Sorry, this week is crazy, so I probably can't until at least the weekend. > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson > Attachments: SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856679#comment-15856679 ] Mike Drob commented on SOLR-10020: -- [~erickerickson] - Do you have time to look at this patch? > CoreAdminHandler silently swallows some errors > -- > > Key: SOLR-10020 > URL: https://issues.apache.org/jira/browse/SOLR-10020 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson > Attachments: SOLR-10020.patch > > > With the setup on SOLR-10006, after removing some index files and starting > that Solr instance I tried issuing a REQUESTRECOVERY command and it came back > as a success even though nothing actually happened. When the core is > accessed, a core init exception is returned by subsequent calls to getCore(). > There is no catch block after the try so no error is returned. > Looking through the code I see several other commands that have a similar > pattern: > FORCEPREPAREFORLEADERSHIP_OP > LISTSNAPSHOTS_OP > getCoreStatus > and perhaps others. getCore() can throw an exception, about the only explicit > one it does throw is if the core has an initialization error. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
