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

ASF GitHub Bot commented on ZOOKEEPER-2849:
-------------------------------------------

Github user brian-lininger commented on a diff in the pull request:

    https://github.com/apache/zookeeper/pull/419#discussion_r151766328
  
    --- Diff: src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java 
---
    @@ -946,7 +946,8 @@ protected Election createElectionAlgorithm(int 
electionAlgorithm){
                     le = new AuthFastLeaderElection(this, true);
                     break;
                 case 3:
    -                qcm = new QuorumCnxManager(this);
    +                qcm = new QuorumCnxManager(this,
    +                    ExponentialBackoffStrategy.builder().build());
    --- End diff --
    
    Agreed, included in my upcoming push.


> Quorum port binding needs exponential back-off retry
> ----------------------------------------------------
>
>                 Key: ZOOKEEPER-2849
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2849
>             Project: ZooKeeper
>          Issue Type: Improvement
>          Components: quorum
>    Affects Versions: 3.4.6, 3.5.3
>            Reporter: Brian Lininger
>            Assignee: Brian Lininger
>            Priority: Minor
>
> Recently we upgraded the AWS instance type we use for running out ZooKeeper 
> nodes, and by doing so we're intermittently hitting an issue where ZooKeeper 
> cannot bind to the server election port because the IP is incorrect.  This is 
> due to name resolution in Route53 not being in sync when ZooKeeper starts on 
> the more powerful EC2 instances.  Currently in QuorumCnxManager.Listener, we 
> only attempt to bind 3 times with a 1s sleep between retries, which is not 
> long enough.  
> I'm proposing to change this to follow an exponential back-off type strategy 
> where each failed attempt causes a longer sleep between retry attempts.  This 
> would allow for Zookeeper to gracefully recover when the host is 
> misconfigured, and subsequently corrected, without requiring the process to 
> be restarted while also minimizing the impact to the running instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to