You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@curator.apache.org by "kezhuw (via GitHub)" <gi...@apache.org> on 2023/05/17 16:13:12 UTC

[GitHub] [curator] kezhuw opened a new pull request, #462: CURATOR-671: Make sure success LeaderSelector::requeue after observing hasLeadership and then !hasLeadership

kezhuw opened a new pull request, #462:
URL: https://github.com/apache/curator/pull/462

   `TestLeaderSelectorCluster.testLostRestart` depends on success `LeaderSelector::requeue` after observing `hasLeadership` and then `!hasLeadership`. #446(CURATOR-518) breaks this.
   
   Instead of simply looping till success `LeaderSelector::requeue`, I tend to revert to old behavior as it was that since its introduce in eb4d2aaf7702e7e5ffbf1c1dd8544e88b1171045.
   
   Though, we can't depend this in case of no leadership was ever granted. In this case, when session expired, I guess looping on `requeue` may be the only option. Anyway, `requeue` is somewhat hard to use correctly.


-- 
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: commits-unsubscribe@curator.apache.org

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


[GitHub] [curator] kezhuw merged pull request #462: CURATOR-671: Make sure success LeaderSelector::requeue after observing hasLeadership and then !hasLeadership

Posted by "kezhuw (via GitHub)" <gi...@apache.org>.
kezhuw merged PR #462:
URL: https://github.com/apache/curator/pull/462


-- 
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: commits-unsubscribe@curator.apache.org

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