[
https://issues.apache.org/jira/browse/SOLR-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132960#comment-14132960
]
Alan Woodward commented on SOLR-6511:
-------------------------------------
I think you might have some extra stuff on the end of the patch?
Digging a bit further into the logs, maxTries is set to 1 because
ensureReplicaInLeaderInitiatedRecovery throws a SessionExpiredException
(presumably because ZK has noticed the network blip and removed the relevant
ephemeral node). Maybe maxTries should *always* be set to 120?
One thing that might be nice here would be to add a utility method to
ZkController called something like ensureLeadership(CloudDescriptor cd), which
checks if the core described by the CloudDescriptor really is the current
leader according to ZK, and throws an exception if it isn't.
> 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
