[
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153164#comment-15153164
]
Scott Blum commented on SOLR-8696:
----------------------------------
Actually on second thought, to become the new Overseer, you would have had to
observe the ephemeral node disappear for the previous overseer. If you've
observed that, and subsequently updated yourself as overseer leader, you would
have had to observe all previous cluster state changes committed by the
previous Overseer. So I think it's actually fine in that case.
> Optimize overseer + startup
> ---------------------------
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Affects Versions: 5.4.1
> Reporter: Scott Blum
> Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.
> That means if there is currently no overseer, there is ironically no one to
> actually service the down state changes it's waiting on. This particularly
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all
> Overseer operations. This isn't necessary because ZkStateReader keeps itself
> up to date.
--
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
