zookeeper Have smaller server identifier

zookeeper 的一个节点启动时候报错：

2011-02-10 15:16:24,128 - INFO  [QuorumPeer:/0:0:0:0:0:0:0:0:2188:FastLeaderElection@683] - Notification time out: 60000
2011-02-10 15:16:24,128 - INFO  [QuorumPeer:/0:0:0:0:0:0:0:0:2188:FastLeaderElection@689] - Notification: 2, 0, 1, 2, LOOKING, LOOKING, 2
2011-02-10 15:16:24,128 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connection: (3, 2)
2011-02-10 15:16:24,129 - INFO  [QuorumPeer:/0:0:0:0:0:0:0:0:2188:FastLeaderElection@799] - Notification: 9, 8589934592, 3, 2, LOOKING, FOLLOWING, 0
2011-02-10 15:16:24,129 - INFO  [QuorumPeer:/0:0:0:0:0:0:0:0:2188:FastLeaderElection@799] - Notification: 9, 8589934592, 3, 2, LOOKING, FOLLOWING, 1
2011-02-10 15:16:24,129 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connection: (4, 2)
2011-02-10 15:16:24,130 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connection: (5, 2)
2011-02-10 15:16:24,131 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connection: (6, 2)
2011-02-10 15:16:24,132 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connection: (7, 2)
2011-02-10 15:16:24,132 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connection: (8, 2)
2011-02-10 15:16:24,133 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connection: (9, 2)
2011-02-10 15:16:24,134 - INFO  [WorkerSender Thread:QuorumCnxManager@162] - Have smaller server identifier, so dropping the connec

 可能是zookeeper 的一个bug 。 

 狂google 就找到如下一个像样的说法：

Thanks for detailed assessment, Vishal. In Step b, the fact that the process believes it is the leader is not a problem, and it happens because we queue notification messages during leader election.

The real issue is that 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.

I noticed that this follower check was not there before (not present in 3.0 branch), and it might have been introduced when we did the observer reorganization. For now I propose that we move line Leader.java:281 to Leader.java:470. It simply changes the point in which we set the last processed zxid to one in which we know that a quorum of followers supports the leader. I reasoned a bit about it and verified that tests pass.

A patch for the change I'm proposing is trivial, but a unit test will require some work, so I'd rather hear opinions first. Also, please note that this problem is not related to the topic of this jira, so we might consider working on a different jira from this point on.

 可由于我用的是cloudera 的zookeeper 所以不能用其最近版（CDH3 没用zookeeper的最新版）

 最后我的解决方法是：

重启系统。。。。