[
https://issues.apache.org/jira/browse/ZOOKEEPER-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280916#comment-14280916
]
Jared Cantwell commented on ZOOKEEPER-1865:
-------------------------------------------
We just hit this in our internal testing today too.
connect() throws a SocketTimeoutException if the specified timeout was reached.
This isn't perfect, but could this be leveraged to assume connect was "fast"
if that exception wasn't thrown, and it was "slow" otherwise? Unfortunately,
if connect() takes just under the timeout to throw a different error, then
we'll "lose" that time. Probably not ideal, but wanted to suggest it as an
option.
> Fix retry logic in Learner.connectToLeader()
> ---------------------------------------------
>
> Key: ZOOKEEPER-1865
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1865
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Reporter: Thawan Kooburat
> Assignee: Edward Carter
> Fix For: 3.5.1
>
> Attachments: ZOOKEEPER-1865.patch
>
>
> We discovered a long leader election time today in one of our prod ensemble.
> Here is the description of the event.
> Before the old leader goes down, it is able to announce notification message.
> So 3 out 5 (including the old leader) elected the old leader to be a new
> leader for the next epoch. While, the old leader is being rebooted, 2 other
> machines are trying to connect to the old leader. So the quorum couldn't
> form until those 2 machines give up and move to the next round of leader
> election.
> This is because Learner.connectToLeader() use a simple retry logic. The
> contract for this method is that it should never spend longer that initLimit
> trying to connect to the leader. In our outage, each sock.connect() is
> probably blocked for initLimit and it is called 5 times.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
