[
https://issues.apache.org/jira/browse/SOLR-10020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
