[
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: [email protected]
For additional commands, e-mail: [email protected]
