curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Zimmerman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-280) LeaderLatch doesn't work when using a zookeeper chroot
Date Tue, 08 Nov 2016 20:13:58 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15648674#comment-15648674
] 

Jordan Zimmerman commented on CURATOR-280:
------------------------------------------

>> But "/" is no more special than any other parent path

That's not true. The root path always exists by definition. That you can "create" it when
in chroot is an oddity of ZK. However, I suggest making a new issue that specifically asks
that creatingParentsIfNeeded also create "/". My concern is that there is a performance penalty
for this when it's almost never used. Let's see what the other committers think. Or maybe
we can somehow make it optional.

> LeaderLatch doesn't work when using a zookeeper chroot
> ------------------------------------------------------
>
>                 Key: CURATOR-280
>                 URL: https://issues.apache.org/jira/browse/CURATOR-280
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: 2.9.0, 2.9.1
>            Reporter: Vincent Bernat
>
> Hey!
> When using a ZK connection-string with a chroot (for example {{localhost:2181/chroot}}),
the leader election by LeaderLatch doesn't work. This may be similar to CURATOR-270. If I
query {{.getParticipants}}, I get:
> {code}
>       Actual: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
NoNode for /test4
>               org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>               org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
>               org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1590)
>               org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:214)
>               org.apache.curator.framework.imps.GetChildrenBuilderImpl$3.call(GetChildrenBuilderImpl.java:203)
>               org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:107)
>               org.apache.curator.framework.imps.GetChildrenBuilderImpl.pathInForeground(GetChildrenBuilderImpl.java:199)
>               org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:191)
>               org.apache.curator.framework.imps.GetChildrenBuilderImpl.forPath(GetChildrenBuilderImpl.java:38)
>               org.apache.curator.framework.recipes.locks.LockInternals.getSortedChildren(LockInternals.java:150)
>               org.apache.curator.framework.recipes.locks.LockInternals.getParticipantNodes(LockInternals.java:132)
>               org.apache.curator.framework.recipes.leader.LeaderLatch.getParticipants(LeaderLatch.java:430)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message