lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Blum (JIRA)" <>
Subject [jira] [Commented] (SOLR-8696) Optimize overseer + startup
Date Sun, 21 Feb 2016 04:09:18 GMT


Scott Blum commented on SOLR-8696:


Yes, I get the breakpoint in OverseerCollectionMessageHandler#addReplica.  I'm trying to follow
up on [~shalinmangar]'s request to add a wait loop at the end of that method.  But where I'm
struggling is, I don't actually understand where and how the ZK cluster state ever gets updated
in legacy mode.  Who updates the ZK cluster state as a result of OverseerCollectionMessageHandler#addReplica?

> Optimize overseer + startup
> ---------------------------
>                 Key: SOLR-8696
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message