[GitHub] [curator] woaishixiaoxiao edited a comment on pull request #398: fix the bug of double leader when use LeaderLatch to select the leader

[GitBox <gi...@apache.org>]

woaishixiaoxiao edited a comment on pull request #398:
URL: https://github.com/apache/curator/pull/398#issuecomment-954646817


   > @woaishixiaoxiao thanks for sharing your fix, do you think that we can add a test case to cover this change ?
   
   OK. I will  try it.   
   and  I find another question related to the leader-selection scenari. When zkServer switch the leader and then returns to normal, all clients will execute state switching: connected->suspend->reconn
   Because leaderlatch processing the reconn state will reset leader status, that is mean first set itself leader status false and then  delete old temporary sequence Node and create a new one.   This operation will cause the business side to perform a leader switch multiple.  Some businesses don’t want to see such frequent switchovers happen such as mq.  Also this operation will cause  nodeDeleteEvent push once from zk server but client execute multiple times  nodeDeleteCallback on same path because client saves mutiple watch local(create new path will getchild and listen.  and prenodedeleteEvent also will getchild and listen ). 
   Why don't we replace SessionConnectionStateErrorPolicy with StandardConnectionStateErrorPolicy? The above phenomenon will be avoided


-- 
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.

To unsubscribe, e-mail: dev-unsubscribe@curator.apache.org

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