[
https://issues.apache.org/jira/browse/SOLR-9439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449719#comment-15449719
]
ASF subversion and git services commented on SOLR-9439:
-------------------------------------------------------
Commit 6bf9513b9385a53557dc0849eb36a062aceb8e8c in lucene-solr's branch
refs/heads/branch_6x from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6bf9513 ]
SOLR-9439: The delete shard API has been made more resilient against failures
resulting from non-existent cores.
(cherry picked from commit 02b97a2)
> Shard split clean up logic for older failed splits is faulty
> ------------------------------------------------------------
>
> Key: SOLR-9439
> URL: https://issues.apache.org/jira/browse/SOLR-9439
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: 4.10.4, 5.5.2, 6.1
> Reporter: Shalin Shekhar Mangar
> Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: Lucene-Solr-tests-master.8015.log.gz,
> SOLR-9439-fix-deleteshard.patch, SOLR-9439-fix-deleteshard.patch,
> SOLR-9439.patch, SOLR-9439.patch, SOLR-9439.patch
>
>
> In case a split finds that previous sub-shards exist in construction or
> recovery state. it tries to clean them up by invoking deleteshard API.
> However, the clean up logic tries to invoke deleteshard on the same
> sub-shards as many times as the requested number of sub-ranges. Such repeat
> calls to deleteshard fail and therefore fail the entire shard split operation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
