[
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)
