[
https://issues.apache.org/jira/browse/SOLR-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058566#comment-14058566
]
Shalin Shekhar Mangar commented on SOLR-6238:
---------------------------------------------
More tests are always welcome.
The leader initiated recovery doesn't actually cover this particular fail so
I'm surprised that it doesn't reproduce after 4.7. Please help me understand
the sequence of operations:
{quote}
Leader -> Lost Connection with ZK
Replica -> Became leader
{quote}
If the leader lost its connection with ZK then it should've rejoined election
on reconnect. If so, why was an add request on this (old) leader successful?
I'll take a look at your patch.
> Specialized test case for leader recovery scenario
> --------------------------------------------------
>
> Key: SOLR-6238
> URL: https://issues.apache.org/jira/browse/SOLR-6238
> Project: Solr
> Issue Type: Improvement
> Reporter: Varun Thacker
> Priority: Minor
> Fix For: 4.10
>
> Attachments: SOLR-6238.patch
>
>
> A scenario which could happen at least before the addition of
> LeaderInitiatedRecoveryThread I think. Also this can happen only if one is
> using a non cloud aware client ( which might be quite a few users ) given
> that we have only SolrJ
> Events are in chronological order -
> Leader -> Lost Connection with ZK
> Replica -> Became leader
> Leader -> add document is successful. Forwards it to the replica
> Replica -> add document is unsuccessful as it is the leader and the request
> says it is coming from a leader
> So as of now the the Replica(new leader) won't have the doc but the
> leader(old leader) will have the document.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
