hi, i am a deleloper from China, when i am reading code "FastLeaderElection.java", i am a bit puzzled.
First one :
i am thiking if this code  
return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) && (newZxid > curZxid)) || ((newZxid == curZxid) && (newId > curId)));

can be replaced with
return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) && (newZxid > curZxid)) || ((newZxid == curZxid) && (newId > proposedLeader)));

i think when replaced, it may be running more efficiently.
Second one:
And when looking at this following part, i am still puzzled
 case LEADING:
      /*
       * Consider all notifications from the same epoch
       * together.
       */
      if (n.electionEpoch == logicalclock) {
       recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch,
         n.peerEpoch));
       if (termPredicate(recvset, new Vote(n.leader, n.zxid, n.electionEpoch,
         n.peerEpoch, n.state))
         && checkLeader(outofelection, n.leader, n.electionEpoch)) {
        self.setPeerState((n.leader == self.getId()) ? ServerState.LEADING
          : learningState());

        Vote endVote = new Vote(n.leader, n.zxid, n.peerEpoch);
        leaveInstance(endVote);
        return endVote;
       }
      }
i think outofelection have nothing to do in this part, is that so?

and can I replace it like this?
checkLeader(recvset, n.leader, n.electionEpoch))
i hope to hear from you! Thank you!^_^
2012-03-08

chen-hongqin

Hi Chen-hongqin, In general it is best to propose code changes using jiras.

On Mar 8, 2012, at 10:25 AM, chen-hongqin wrote:

> hi, i am a deleloper from China, when i am reading code "FastLeaderElection.java", i am a bit puzzled.
> First one :
> i am thiking if this code  
> return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) && (newZxid > curZxid)) || ((newZxid == curZxid) && (newId > curId)));
>
> can be replaced with
> return ((newEpoch > curEpoch) || ((newEpoch == curEpoch) && (newZxid > curZxid)) || ((newZxid == curZxid) && (newId > proposedLeader)));
>
> i think when replaced, it may be running more efficiently.
>

I don't see how it makes the election process more efficient. As presented, I don't see any significant gain here.

>
> Second one:
> And when looking at this following part, i am still puzzled
> case LEADING:
>      /*
>       * Consider all notifications from the same epoch
>       * together.
>       */
>      if (n.electionEpoch == logicalclock) {
>       recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch,
>         n.peerEpoch));
>       if (termPredicate(recvset, new Vote(n.leader, n.zxid, n.electionEpoch,
>         n.peerEpoch, n.state))
>         && checkLeader(outofelection, n.leader, n.electionEpoch)) {
>        self.setPeerState((n.leader == self.getId()) ? ServerState.LEADING
>          : learningState());
>
>        Vote endVote = new Vote(n.leader, n.zxid, n.peerEpoch);
>        leaveInstance(endVote);
>        return endVote;
>       }
>      }
> i think outofelection have nothing to do in this part, is that so?
>

It does because the notification comes from a server that is leading and consequently out of election.

> and can I replace it like this?
> checkLeader(recvset, n.leader, n.electionEpoch))
>
>

I don't think so, it sounds wrong to me.

-Flavio
flavio
junqueira
senior research scientist
 
[EMAIL PROTECTED]
direct +34 93-183-8828
 
avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300    fax (408) 349 3301