[GitHub] curator issue #243: [Fix] Curator-444

2018-12-15 Thread egor-ryashin
Github user egor-ryashin commented on the issue: https://github.com/apache/curator/pull/243 @Randgalt no, it doesn't recover, only a restart helps. ---

[GitHub] curator issue #243: [Fix] Curator-444

2018-12-11 Thread Randgalt
Github user Randgalt commented on the issue: https://github.com/apache/curator/pull/243 Please read this tech note and see if it applies: https://issues.apache.org/jira/browse/CURATOR-460 ---

[GitHub] curator issue #243: [Fix] Curator-444

2018-12-11 Thread Randgalt
Github user Randgalt commented on the issue: https://github.com/apache/curator/pull/243 @egor-ryashin For `LeaderLatch` calls `setLeadership(false);` when the connection is lost. `LeaderSelector` is a bit more complicated but if you use the recommended `LeaderSelectorListenerAdapter`

[GitHub] curator issue #243: [Fix] Curator-444

2018-12-11 Thread egor-ryashin
Github user egor-ryashin commented on the issue: https://github.com/apache/curator/pull/243 @Randgalt I've actually seen several leaders working several minutes till I restart them. My guess, right now, that can happen when the leader has lost connection for a spell. For example,

[GitHub] curator issue #243: [Fix] Curator-444

2018-12-10 Thread Randgalt
Github user Randgalt commented on the issue: https://github.com/apache/curator/pull/243 @borjab and @egor-ryashin I just ran the test in this PR multiple times with the fix in LeaderLatch commented out and the tests always pass. It's important to note that if you don't use the default

[GitHub] curator issue #243: [Fix] Curator-444

2018-11-20 Thread Randgalt
Github user Randgalt commented on the issue: https://github.com/apache/curator/pull/243 > And ourIndex = 2, why would we add a watcher for the child 1? This prevents thundering herds when ZNodes are deleted. A given client only needs to watch the ZNode previous to it thereby it onl

[GitHub] curator issue #243: [Fix] Curator-444

2018-11-20 Thread cammckenzie
Github user cammckenzie commented on the issue: https://github.com/apache/curator/pull/243 This is just done for efficiency. Each client involved in the leader election only cares when the child before it disconnects, because that implies that it should now become leader. If any of th

[GitHub] curator issue #243: [Fix] Curator-444

2018-11-20 Thread egor-ryashin
Github user egor-ryashin commented on the issue: https://github.com/apache/curator/pull/243 We've got continuous issues with that bug (two critical nodes becoming leaders simultaneously begin to damage the work of each other), and I would like this work to be continued, though I see i

[GitHub] curator issue #243: [Fix] Curator-444

2017-12-04 Thread cammckenzie
Github user cammckenzie commented on the issue: https://github.com/apache/curator/pull/243 Thanks! ---

[GitHub] curator issue #243: [Fix] Curator-444

2017-12-04 Thread borjab
Github user borjab commented on the issue: https://github.com/apache/curator/pull/243 Thanks for the feedback. You are right that the test has a lot of room for improvement. I will work on the tests as requested. ---

[GitHub] curator issue #243: [Fix] Curator-444

2017-11-28 Thread borjab
Github user borjab commented on the issue: https://github.com/apache/curator/pull/243 Fix now includes test to reproduce error. ---