[
https://issues.apache.org/jira/browse/CURATOR-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zili Chen resolved CURATOR-521.
-------------------------------
Assignee: Zili Chen (was: Kezhu Wang)
Resolution: Invalid
No. We check closeMode is not null in constructor:
{code:java}
public LeaderLatch(CuratorFramework client, String latchPath, String id,
CloseMode closeMode) {
this.client =
Preconditions.checkNotNull(client, "client cannot be
null").newWatcherRemoveCuratorFramework();
this.latchPath = PathUtils.validatePath(latchPath);
this.id = Preconditions.checkNotNull(id, "id cannot be null");
this.closeMode = Preconditions.checkNotNull(closeMode, "closeMode
cannot be null");
}
{code}
> LeaderLatch closed with CloseMode=null does not close
> ------------------------------------------------------
>
> Key: CURATOR-521
> URL: https://issues.apache.org/jira/browse/CURATOR-521
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 4.2.0
> Reporter: Yuri Tceretian
> Assignee: Zili Chen
> Priority: Trivial
>
> The class LeaderLatch has two methods `close`, one of them accepts argument
> `CloseMode`. If the argument is null (unlikely but still possible) the
> instance changes the state to CLOSED but does not really close anything
> because throws a runtime exception `closeMode cannot be null` right after
> changing the status.
> [https://github.com/apache/curator/blob/a3514d87b1036716e5dc9877c9980fdd81440458/curator-recipes/src/main/java/org/apache/curator/framework/recipes/leader/LeaderLatch.java#L201-L205]
> The quickest fix is to just swap preconditions checks. The more correct
> solution is to change state in the try block after the client removed all
> watchers (or in finally block). It should not break anything because the
> method is synchronized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
