[ https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153015#comment-15153015 ]
Mark Miller commented on SOLR-8696: ----------------------------------- In one of the leader election improvement patches, I think I took the wait out altogether. Starting the Overseer election first makes sense though. bq. Additionally, we're doing an unnecessary ZkStateReader forced refresh on all Overseer operations. This isn't necessary because ZkStateReader keeps itself up to date. It keeps itself up to date, but with some delay. Are we sure we don't need to know we have the latest state at that point? What about the case when we just took over for another Overseer? No races? > 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