[
https://issues.apache.org/jira/browse/SOLR-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14639380#comment-14639380
]
Shalin Shekhar Mangar commented on SOLR-7819:
---------------------------------------------
[~andyetitmoves] - It looks like the commits for SOLR-7245 only added a
retryOnConnLoss parameter but it was never used inside the
ZkController.updateLeaderInitiatedRecoveryState method?
Also, now that I am thinking about this change, is it really safe? For example,
if a leader was not able to write to a 'live' replica, and during the LIR
process if the leader couldn't complete a ZK operation (because
retryOnConnLoss=false) then LIR won't be set and updates can be missed. Also,
the code as it is currently written, bails on a ConnectionLossException and
doesn't even start a LIR thread which is bad.
I think not having a thread wait for LIR related activity is a noble cause but
we should move the entire LIR logic to a background thread which must retry on
connection loss until it either succeeds or a session expired exception is
thrown.
Thoughts?
> ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect
> retryOnConnLoss
> ------------------------------------------------------------------------------------
>
> Key: SOLR-7819
> URL: https://issues.apache.org/jira/browse/SOLR-7819
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.2, 5.2.1
> Reporter: Shalin Shekhar Mangar
> Labels: Jepsen
> Fix For: 5.3, Trunk
>
>
> SOLR-7245 added a retryOnConnLoss parameter to
> ZkController.ensureReplicaInLeaderInitiatedRecovery so that indexing threads
> do not hang during a partition on ZK operations. However, some of those
> changes were unintentionally reverted by SOLR-7336 in 5.2.
> I found this while running Jepsen tests on 5.2.1 where a hung update managed
> to put a leader into a 'down' state (I'm still investigating and will open a
> separate issue about this problem).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
