You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2018/10/20 22:29:00 UTC
[jira] [Updated] (SOLR-12889) Clean up CoreAdmin behavior and
responses when acting on cores that failed to initialize
[ https://issues.apache.org/jira/browse/SOLR-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shawn Heisey updated SOLR-12889:
--------------------------------
Description:
Solr isn't behaving quite correctly when performing CoreAdmin actions on cores that exist, but failed to initialize.
* RELOAD works. That was made possible by SOLR-10021.
* UNLOAD works, and can even delete directories if asked to.
* RENAME works, but Solr must be restarted for the admin UI to reflect the new name in the "SolrCore Initialization Failures" message.
* SWAP doesn't actually work, but returns a response that *LOOKS* like it worked.
I didn't try the other actions, because it doesn't really make any sense to allow those on a core that failed.
What I see as things that need to be checked or implemented when acting on failed cores:
* SWAP
** Fail fast.
** OR make it work properly. If we choose this, adjust the core name in the initFailures part of the STATUS response.
* RENAME
** Fail fast.
** OR make it work properly. If we choose this, adjust the core name in the initFailures part of the STATUS response.
* UNLOAD
** This looks like it behaves correctly. Tried it with deleteInstanceDir=true and it did wipe out the whole core.
* Other actions not already mentioned
** Fail fast
Something else to consider: Get rid of the initFailures part of the STATUS response. List all cores, even those that failed. Include a boolean item in the response to indicate whether initialization succeeded, and only list some of the full information for a failed core. This would make implementing SOLR-12863 easier.
was:
Solr isn't behaving quite correctly when performing CoreAdmin actions on cores that exist, but failed to initialize.
* RELOAD works. That was made possible by SOLR-10021.
* UNLOAD works, and can even delete directories if asked to.
* RENAME works, but Solr must be restarted for the admin UI to reflect the new name in the "SolrCore Initialization Failures" message.
* SWAP doesn't actually work, but returns a response that *LOOKS* like it worked.
I didn't try the other actions, because it doesn't really make any sense to allow those on a core that failed.
What I see as things that need to be checked or implemented when acting on failed cores:
* SWAP
** Fail fast.
** OR make it work properly. If we choose this, adjust the core name in the initFailures part of the STATUS response.
* RENAME
** Fail fast.
** OR make it work properly. If we choose this, adjust the core name in the initFailures part of the STATUS response.
* Other actions not already mentioned
** Fail fast
Something else to consider: Get rid of the initFailures part of the STATUS response. List all cores, even those that failed. Include a boolean item in the response to indicate whether initialization succeeded, and only list some of the full information for a failed core. This would make implementing SOLR-12863 easier.
> Clean up CoreAdmin behavior and responses when acting on cores that failed to initialize
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-12889
> URL: https://issues.apache.org/jira/browse/SOLR-12889
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.5
> Reporter: Shawn Heisey
> Priority: Minor
>
> Solr isn't behaving quite correctly when performing CoreAdmin actions on cores that exist, but failed to initialize.
> * RELOAD works. That was made possible by SOLR-10021.
> * UNLOAD works, and can even delete directories if asked to.
> * RENAME works, but Solr must be restarted for the admin UI to reflect the new name in the "SolrCore Initialization Failures" message.
> * SWAP doesn't actually work, but returns a response that *LOOKS* like it worked.
> I didn't try the other actions, because it doesn't really make any sense to allow those on a core that failed.
> What I see as things that need to be checked or implemented when acting on failed cores:
> * SWAP
> ** Fail fast.
> ** OR make it work properly. If we choose this, adjust the core name in the initFailures part of the STATUS response.
> * RENAME
> ** Fail fast.
> ** OR make it work properly. If we choose this, adjust the core name in the initFailures part of the STATUS response.
> * UNLOAD
> ** This looks like it behaves correctly. Tried it with deleteInstanceDir=true and it did wipe out the whole core.
> * Other actions not already mentioned
> ** Fail fast
> Something else to consider: Get rid of the initFailures part of the STATUS response. List all cores, even those that failed. Include a boolean item in the response to indicate whether initialization succeeded, and only list some of the full information for a failed core. This would make implementing SOLR-12863 easier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org