[jira] [Updated] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-10020: -- Attachment: SOLR-10020.patch Same patch with CHANGES attribution. > 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] [Updated] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-10020: - Attachment: SOLR-10020.patch Adding a test, and also unwrapping a layer of async because DefaultSolrCoreState.doRecovery already uses a separate thread/executor, so we don't need to do it directly in the CoreAdminOperation. > 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] [Updated] (SOLR-10020) CoreAdminHandler silently swallows some errors
[ https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated SOLR-10020: - Attachment: SOLR-10020.patch Looked at this again and realized I had the core close in the wrong spot. New patch attached. > 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 > > > 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
