[
https://issues.apache.org/jira/browse/SOLR-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140974#comment-14140974
]
Timothy Potter commented on SOLR-6511:
--------------------------------------
I now have a test case that duplicates Alan's scenario exactly, which is good.
In devising a fix, the following problem has come up -- the request has been
accepted locally on the used to be leader and is failing on one of the replicas
because of the leader change ("Request says it is coming from leader, but we
are the leader").
So does the old leader (the one receiving the error back from the new leader)
try to be clever and forward the request to the leader as any replica would do
under normal circumstances? Keep in mind that this request has already been
accepted locally and possibly on other replicas. Or does this old leader just
propagate the failure back to the client and let it decide what to do? Guess it
comes down to whether we think its safe to just re-process a request? Seems
like it would be but wanted feedback before assuming that.
> Fencepost error in LeaderInitiatedRecoveryThread
> ------------------------------------------------
>
> Key: SOLR-6511
> URL: https://issues.apache.org/jira/browse/SOLR-6511
> Project: Solr
> Issue Type: Bug
> Reporter: Alan Woodward
> Assignee: Timothy Potter
> Attachments: SOLR-6511.patch
>
>
> At line 106:
> {code}
> while (continueTrying && ++tries < maxTries) {
> {code}
> should be
> {code}
> while (continueTrying && ++tries <= maxTries) {
> {code}
> This is only a problem when called from DistributedUpdateProcessor, as it can
> have maxTries set to 1, which means the loop is never actually run.
--
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
