[
https://issues.apache.org/jira/browse/SOLR-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981460#comment-15981460
]
Mike Drob commented on SOLR-9555:
---------------------------------
Looking at my patch again, I can't tell if there is a really subtle bug going
on with the ZK watches or not. When setting the LIR state to down, we will add
a watch that will notify us when the LIR state changes next and if it's no
longer down (i.e. recovering) then we can un-blacklist the follower for
updates. However, if it's still down when we get that request (or down again, I
guess?) then we won't get any notifications the next time it actually changes
state to recovering. Except whatever set the second down state should have also
set a new watch, so I think we're still fine. Would appreciate somebody taking
a close look at this though.
Also, it's possible that we might need to call
{{replicasInLeaderInitiatedRecovery.remove(znodePath);}} when we get a prep
recovery request instead?
> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -----------------------------------------------------------------------------
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Alan Woodward
> Attachments: SOLR-9555.patch, SOLR-9555-WIP-2.patch,
> SOLR-9555-WIP-3.patch, SOLR-9555-WIP.patch
>
>
> See
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull
> for an example
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
