[ 
https://issues.apache.org/jira/browse/SOLR-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159413#comment-15159413
 ] 

Scott Blum commented on SOLR-8696:
----------------------------------

Thanks.  Way beyond the scope of this ticket, I was just curious about it.  It 
seemed a little silly on the face of it, because solr already has to tolerate 
long periods of things being marked ACTIVE in cluster state that aren't really 
up, since a node can crash and take a long time to recover.  I feel like all a 
recovering node really needs to do is verify that all the cores it owns are in 
the correct state immediately before publishing its live node entry.  We could 
save a lot of unnecessary overseer ops here on node restart.

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 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
>            Assignee: Mark Miller
>              Labels: patch, performance, solrcloud, startup
>         Attachments: SOLR-8696.patch, 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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to