[
https://issues.apache.org/jira/browse/SOLR-17692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17940365#comment-17940365
]
ASF subversion and git services commented on SOLR-17692:
--------------------------------------------------------
Commit 244a520c29db0d922ade6d886ff674f915abcbae in solr's branch
refs/heads/branch_9x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=244a520c29d ]
SOLR-17692: Abort ongoing fetches on core close (#3292)
RecoveryStrategy.close aims to stop replication when the surrounding
core is closed, but doesn't quite manage in all cases. In particular,
the 'closed' flag isn't able to preempt replication once the
IndexFetcher has started pulling files.
This commit aims to fix this by having RecoveryStrategy.close invoke
ReplicationHandler.abortFetch, which sets a flag that *is* noticed by
IndexFetcher. This should ensure that DELETEREPLICA calls and other
core-shutdown paths don't block on long-running recovery operations.
> DELETEREPLICA should preempt full-recovery instead of waiting for completion
> ----------------------------------------------------------------------------
>
> Key: SOLR-17692
> URL: https://issues.apache.org/jira/browse/SOLR-17692
> Project: Solr
> Issue Type: Bug
> Components: replication (java), SolrCloud
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I recently deleted a NRT replica that was in the middle of a full-recovery
> and was a bit surprised to see that the "delete" blocked waiting for the
> recovery to finish. This is a minor pain when the index is small, but
> becomes a huge waste of administrator time (and network bandwidth!) as index
> sizes grow.
> There's some plumbing in Solr that attempts to preempt recovery during a
> DELETE, but it appears that it seems that it mostly comes into play during
> peer-sync and "background replication" scenarios (i.e. PULL and TLOG replicas
> that do full-recovery during normal operation). Preemption doesn't seem to
> work once a recovering core is in the midst of a "full recovery". We should
> modify this code that it stops full-recovery as well, unless there's some
> compelling reason this was avoided in the initial implementation?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
