[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org