Return-Path: X-Original-To: apmail-curator-dev-archive@minotaur.apache.org Delivered-To: apmail-curator-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 58C3818F68 for ; Tue, 10 Nov 2015 16:41:11 +0000 (UTC) Received: (qmail 18498 invoked by uid 500); 10 Nov 2015 16:41:11 -0000 Delivered-To: apmail-curator-dev-archive@curator.apache.org Received: (qmail 18402 invoked by uid 500); 10 Nov 2015 16:41:11 -0000 Mailing-List: contact dev-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@curator.apache.org Delivered-To: mailing list dev@curator.apache.org Received: (qmail 18381 invoked by uid 99); 10 Nov 2015 16:41:11 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Nov 2015 16:41:11 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id F1D3C2C1F58 for ; Tue, 10 Nov 2015 16:41:10 +0000 (UTC) Date: Tue, 10 Nov 2015 16:41:10 +0000 (UTC) From: "Mike Drob (JIRA)" To: dev@curator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CURATOR-280) LeaderLatch doesn't work when using a zookeeper chroot MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CURATOR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998877#comment-14998877 ] Mike Drob commented on CURATOR-280: ----------------------------------- I suspect that it will work with an existing chroot node, please try that as a workaround so that your project isn't stuck because of us. Other projects have reported similar errors when using ZK connect strings with a non-existing chroot - a couple examples would be KAFKA-2237 and SOLR-7642. This leads me to believe that none of our recipes will work, providing the same error message, aside from the LeaderLatch fail we've already seen. Will need to think about the proper solution a bit here in terms of user expectations and backwards compatibility. > 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)