[
https://issues.apache.org/jira/browse/SOLR-12261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16451575#comment-16451575
]
ASF subversion and git services commented on SOLR-12261:
--------------------------------------------------------
Commit 5a89f604cdfc6fde68c8e6a5fdfb01f5ac3f732d in lucene-solr's branch
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5a89f60 ]
SOLR-12261: Collection deletion's check for alias membership should
sync() aliases with ZK before throwing an error.
(cherry picked from commit 1370f6b)
> Deleting collections should sync aliases before prematurely failing when
> alias is deleted
> -----------------------------------------------------------------------------------------
>
> Key: SOLR-12261
> URL: https://issues.apache.org/jira/browse/SOLR-12261
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Attachments: SOLR-12261.patch
>
>
> In SOLR-11218 [~erickerickson] ensured that we can't delete a collection that
> is referenced by an alias. However It may be that the alias is deleted but
> the node servicing the request doesn't know about this yet. It should call
> AliasesManager.update() first (which now sync()'s with ZK).
> I believe this is the cause of some sporadic failures to
> org.apache.solr.cloud.AliasIntegrationTest#tearDown which deletes the alias
> then all collections.
> It's debatable if this is an improvement or a bug. Sadly most of SolrCloud
> simply seems to operate this way despite it being eventually consistent. Thus
> users using SolrCloud may have to add sleep()s after calls to Solr admin
> calls :-/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
