[
https://issues.apache.org/jira/browse/SOLR-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15732760#comment-15732760
]
ASF subversion and git services commented on SOLR-9834:
-------------------------------------------------------
Commit 89327187439ca2dfa2d49b5ae2bf327031e6d730 in lucene-solr's branch
refs/heads/branch_6x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8932718 ]
SOLR-9834: A variety of spots in the code can create a collection zk node after
the collection has been removed.
# Conflicts:
# solr/CHANGES.txt
> A variety of spots in the code can create a collection zk node after the
> collection has been removed.
> -----------------------------------------------------------------------------------------------------
>
> Key: SOLR-9834
> URL: https://issues.apache.org/jira/browse/SOLR-9834
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Mark Miller
> Assignee: Mark Miller
> Attachments: SOLR-9834.patch, SOLR-9834.patch
>
>
> The results of this have annoyed me for some time. We should fail rather than
> create the collection node and only ensure the rest of the path exists if the
> collection node did not need to be created.
> Currently, leader elections can trigger on delete and recreate a collection
> zk node that was just removed. I think there was a bit of defense put in
> against that, but I still see it and this is more thorough as well as a step
> towards the ZK=Truth path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
