[ 
https://issues.apache.org/jira/browse/SOLR-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14639404#comment-14639404
 ] 

Ramkumar Aiyengar commented on SOLR-7819:
-----------------------------------------

Duh, this is why we need a good test for this (I gave up after trying a bit in 
the original ticket), and I need to pay attention to automated merges more. 
Looks like my initial patch had the change, but when I merged with [your 
changes|https://svn.apache.org/viewvc?view=revision&revision=1666825] for 
SOLR-7109, looks like the local variable use just got removed :(

I get your concern, I think we already do this, look at 
DistributedUpdateProcessor.java around line 883, if we are unable to set the 
LIR node, we start a thread to keep retrying the node set. We just need to 
return false in the connection loss case as well, we currently do it only if 
the node is not live (and hence we didnt even bother setting the node).

> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to