tree 183786b73fdf712686eda896709a5b9c01603b97
parent 4221604facf2447f4ef7789842ac0b8c4a9d4763
author Kezhu Wang <kezhuw@apache.org> 1685528219 +0800
committer GitHub <noreply@github.com> 1685528219 +0800
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJkdx6bCRBK7hj4Ov3rIwAA8eUIAAbsNj1b9ZWL8jZDkhZ94RAG
 lzE1sSb40LRXBtdbczDhEqdpWzjYQ2pZfVA2uTFDBhfIyW7ujvdbPuHhKfTo3n44
 /T9oAsJIavS4dU6pvI7TfuG0IJlPUQWcPCu9P2tBXMmxzh59pFKSoxq3SaGOzh0K
 Y1TzoSGJ0TrPTVba7SbWaGuQAWiwqQRSRiyH3/Prf/P8jFd+W2H/RNU31G7kiOyd
 YRkUSUwYRKi/KR9cd+PEt+WXbhCw4R6n+OjJWjJnvjidnPeVsQ5wFC1TOIP3X8IX
 VEpTnYkNQCaKt/sG/kjsfNPRjOiKTSyDePh+Fu4vk6HQuon5nbHbkG68s+iPNv0=
 =08l+
 -----END PGP SIGNATURE-----
 

CURATOR-671: Make sure success LeaderSelector::requeue after observing hasLeadership and then !hasLeadership (#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.