[
https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859557#comment-13859557
]
Mark Miller commented on SOLR-5593:
-----------------------------------
Great find!
bq. The former shard leader also did not become shard leader because its new
seq number placed it after the existing replicas (LeaderElector
checkIfIamLeader seq <= intSeqs.get(0)).
This I'm surprised to see - when someone cannot be the leader, for instance if
they published a non active state last, they should get back in line - the
original leader should have his chance again...
> shard leader loss due to ZK session expiry
> ------------------------------------------
>
> Key: SOLR-5593
> URL: https://issues.apache.org/jira/browse/SOLR-5593
> Project: Solr
> Issue Type: Improvement
> Reporter: Christine Poerschke
> Attachments: CoreAdminHandler.patch
>
>
> The problem we saw was that the shard leader ceased to be shard leader (in
> our case due to its zookeeper session expiring). The followers thus rejected
> update requests (DistributedUpdateProcessor setupRequest's call to
> ZkStateReader getLeaderRetry) and the leader asked them to recover
> (DistributedUpdateProcessor doFinish). The followers published themselves as
> recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard
> leader loss triggered an election in which none of the followers became the
> leader due to their recovering state (ShardLeaderElectionContext
> shouldIBeLeader). The former shard leader also did not become shard leader
> because its new seq number placed it after the existing replicas
> (LeaderElector checkIfIamLeader seq <= intSeqs.get(0)).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
