You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by GitBox <gi...@apache.org> on 2021/02/03 03:46:08 UTC

[GitHub] [incubator-ratis] amaliujia commented on pull request #409: RATIS-1301. LeaderElection works when Listener is in RaftGroup

amaliujia commented on pull request #409:
URL: https://github.com/apache/incubator-ratis/pull/409#issuecomment-772200643


   > @amaliujia Thanks the patch. I have two questions:
   > 
   > 1. Because all peers will be persisted in storage,  what the persisted data looks like when add listener ? I doubt whether we can identify listener when restart the cluster.
   Can you point the place that persist peers to storage to me? Sounds like we need to differentiate normal peer and listener in  the persisted data. At least in a RaftGroup we have a way to differentiate two kinds of servers. Generally speaking we need an extra bit to indicate a server is a listener.
   
   > 2. Do we need to forbit normal peers sending RequestVote to listener ?
   I think forbidding listener participant voting greatly simplify the implementation while allowing listener join voting seems have no much benefits. One benefit I can think of is listener can help reject candidate whose log might be lagging. But the cost is increasing algorithmic complexity. E.g. need to re-consider majority, should listener be counted or not.
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org