[ https://issues.apache.org/jira/browse/SOLR-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16285501#comment-16285501 ]
Varun Thacker edited comment on SOLR-11685 at 12/11/17 4:33 AM: ---------------------------------------------------------------- The easiest thing we could do is acknowledge that this race condition could happen , and {[doDefensiveChecks}} could throw a type of exception which the client can retry on? was (Author: varunthacker): T > CollectionsAPIDistributedZkTest.testCollectionsAPI fails regularly with > leader mismatch > --------------------------------------------------------------------------------------- > > Key: SOLR-11685 > URL: https://issues.apache.org/jira/browse/SOLR-11685 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Varun Thacker > Attachments: jenkins_7x_257.log, jenkins_master_7045.log, > solr_master_7574.log, solr_master_8983.log > > > I've been noticing lots of failures on Jenkins where the document add get's > rejected because of leader conflict and throws an error like > {code} > ClusterState says we are the leader > (https://127.0.0.1:38715/solr/awhollynewcollection_0_shard2_replica_n2), but > locally we don't think so. Request came from null > {code} > Scanning Jenkins logs I see that these failures have increased since Sept > 28th and has been failing daily. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org