[ https://issues.apache.org/jira/browse/CURATOR-518?focusedWorklogId=849109&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-849109 ]
ASF GitHub Bot logged work on CURATOR-518: ------------------------------------------ Author: ASF GitHub Bot Created on: 04/Mar/23 15:20 Start Date: 04/Mar/23 15:20 Worklog Time Spent: 10m Work Description: kezhuw commented on PR #446: URL: https://github.com/apache/curator/pull/446#issuecomment-1454774272 [CURATOR-518](https://issues.apache.org/jira/browse/CURATOR-518) covers two things I think: 1. `interruptLeadership` did not test `hasLeadership` as what its javadoc says "if this instance has leadership". 2. `interruptLeadership` could break `autoRequeue`. There are different since `interruptLeadership` has two different usages: 1. Public API: we should either change its javadoc or its implementation. 2. Cancel election regardless of leadership in case of session state change. Currently, auto-requeue is done by submit next election in its own task. But `FutureTask.cancel` chould cancel election task before it got a chance to run. Apparently, this is a bug in implementation. Any thoughts ? @eolivelli @tisonkun Issue Time Tracking ------------------- Worklog Id: (was: 849109) Time Spent: 1h (was: 50m) > Curator. LeaderSelector. Two successive calls to interruptLeadership() will > break autoRequeue. > ---------------------------------------------------------------------------------------------- > > Key: CURATOR-518 > URL: https://issues.apache.org/jira/browse/CURATOR-518 > Project: Apache Curator > Issue Type: Improvement > Components: Recipes > Affects Versions: 4.0.1, 4.2.0 > Environment: Windows 8, JRE 1.8.0_181 > Reporter: Bulatov Oleg > Priority: Major > Labels: newbie > Time Spent: 1h > Remaining Estimate: 0h > > h1. Curator. LeaderSelector. Two successive calls to interruptLeadership() > will break autoRequeue > If we set autoRequeue to TRUE. But during execution interruptLeadership() > will be called from another thread before internalRequeue() completed its > work. Then it will break recursive call to internalRequeue(), so that client > will not ask for leadership and get stuck. > We can solve this problem if we check hasLeadership() before calling > interruptLeadership(). But it is strange that such check curator library does > not do internally. -- This message was sent by Atlassian Jira (v8.20.10#820010)