Vishal K commented on ZOOKEEPER-790:

Hi Flavio,

Apologies for not trying the patch sooner. I will  try out the patch soon 
(altough Sergey has pointed out a potential problem).

I am still not conviced why the other two nodes that have formed the cluster 
are in LOOKING state? 
You mentioned that - "The notifications of 1 and 2 say looking because they 
have been queued at the time 1 and 2 were looking for a leader. That's not an 

However, in this case, we have failed a follower and not a leader. Why would 
failure of a follower cause the other two nodes (including the leader) to start 
looking for a leader?
Am I missing something?


> Last processed zxid set prematurely while establishing leadership
> -----------------------------------------------------------------
>                 Key: ZOOKEEPER-790
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: quorum
>    Affects Versions: 3.3.1
>            Reporter: Flavio Junqueira
>            Assignee: Flavio Junqueira
>            Priority: Blocker
>             Fix For: 3.3.2, 3.4.0
>         Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, 
> ZOOKEEPER-790-follower-request-NPE.log, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.patch, ZOOKEEPER-790.travis.log.bz2
> The leader code is setting the last processed zxid to the first of the new 
> epoch even before connecting to a quorum of followers. Because the leader 
> code sets this value before connecting to a quorum of followers 
> (Leader.java:281) and the follower code throws an IOException 
> (Follower.java:73) if the leader epoch is smaller, we have that when the 
> false leader drops leadership and becomes a follower, it finds a smaller 
> epoch and kills itself.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to