[
https://issues.apache.org/jira/browse/SOLR-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283148#comment-16283148
]
Varun Thacker commented on SOLR-11685:
--------------------------------------
{code}
if ((isLeader && !localIsLeader) || (isSubShardLeader && !localIsLeader)) {
log.error("ClusterState says we are the leader, but locally we don't
think so");
+ if (from == null) {
+ //if leader=null means the client sent the request. If we aren't the
leader (the client has old info) return a exception which the client can +retry
on
+ }
throw new SolrException(ErrorCode.SERVICE_UNAVAILABLE,
"ClusterState says we are the leader (" + zkController.getBaseUrl()
+ "/" + req.getCore().getName() + "), but locally we don't think
so. Request came from " + from);
}
{code}
> 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
>
>
> 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
