[
https://issues.apache.org/jira/browse/SOLR-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15836899#comment-15836899
]
Mark Miller commented on SOLR-9555:
-----------------------------------
bq. The potential downside here is that we end up keeping two copies of the
state, but I think it's ok? One is what the replica thinks it is, and one is
what the leader thinks it is
I'm not sure if we really have to end up doing that. We already are
communicating in ZK in a way that the replica can see itself it needs to enter
recovery. I think we just need a strategy for the replica to have watches that
alert it the leader has put it in LIR. The first time it notices this, it can
be sure to go into recovery - it may even be better to only do that and remove
the code that has the leader ask the replica to go into recovery on each
failure. I think we can do that by pre creating some base LIR nodes and then
watch it's children or something along those lines. Each LIR node in ZK could
have a unique version so that we could tell if a new LIR request came in while
responding to one (so start recovery over).
We should assume the replica can simply be alerted to mark itself as down when
it sees it's been marked on LIR. If its too messed up to do that, it should
lose it's zk connection, and if not, I think that's a corner case that needs an
alternate solution.
> 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
>
> See
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull
> for an example
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
