[
https://issues.apache.org/jira/browse/SOLR-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153048#comment-15153048
]
Scott Blum commented on SOLR-8697:
----------------------------------
TBH, the code is pretty hard to follow in its existing form, and a lot of the
theory of operation and design is difficult to distill. There is code that
looks like it's trying to do what you're talking about, but it's buggy.
Take this analysis with like 70% confidence: The existing code has a very hazy
definition of "myself" and "previous registration", from what I can tell. The
previous elect node from a different process qualifies as "myself" in some
cases, so the new process thinks it's already registered when it's not.
> Fix LeaderElector issues
> ------------------------
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.4.1
> Reporter: Scott Blum
> Labels: patch, reliability, solrcloud
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector,
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud. it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer. The old process's ZK leader elect
> node has not yet disappeared, and the new process fails to set appropriate
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join
> the election quickly.
--
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
