[ https://issues.apache.org/jira/browse/SOLR-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15170697#comment-15170697 ]
Mark Miller commented on SOLR-8629: ----------------------------------- This may be as simple as adding code 500 as a success on peersync like we currently do on connect exceptions. My worry is the same as those exceptions though - it may be a very temporary situation, and the affected node may be the best leader candidate. That is why I've been thinking about SOLR-8753. It would be nice to allow a couple of retries of the possible leaders over time in these situations. I think that may be tricky to do nicely with the current code though. > When a prospective leader attempts to sync with it's shard, we should only > fail the sync due to peer sync, not necessarily other exceptions. > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SOLR-8629 > URL: https://issues.apache.org/jira/browse/SOLR-8629 > Project: Solr > Issue Type: Bug > Reporter: Mark Miller > Assignee: Mark Miller > > Otherwise, one screwed up replica can prevent a leader even if there are 100 > other good replicas. -- 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