Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Wed, 5 Nov 2014 05:19:34 +0000 (UTC)
From: "Scott Blum (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12732696.1407448736000.419793.1415164774065@Atlassian.JIRA>
In-Reply-To: <JIRA.12732696.1407448736000@Atlassian.JIRA>
References: <JIRA.12732696.1407448736000@Atlassian.JIRA>
 <JIRA.12732696.1407448736161@arcas>
Subject: [jira] [Commented] (CURATOR-136) Invalid LeaderLatch path never
 errors
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Scott Blum commented on CURATOR-136:
------------------------------------

Should we rename the title of this jira?  I just integrated 2.7.0 to our internal code base, and several things broke due to stricter enforcement of paths.  The release notes (https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314425&version=12327442) basically don't even hint about this as an upgrade issue.  Would changing this jira title change how the release notes are presented?


> Invalid LeaderLatch path never errors
> -------------------------------------
>
>                 Key: CURATOR-136
>                 URL: https://issues.apache.org/jira/browse/CURATOR-136
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.6.0
>            Reporter: John Vines
>            Assignee: Jordan Zimmerman
>             Fix For: 2.7.0
>
>
> I was messing with the LeaderLatch and I noticed some ill behavior for the pathing of it. Given the following code-
> {code}  public static void main(String args[]) throws Exception {
>     TestingServer ts = new TestingServer();
>     CuratorFramework curator = CuratorFrameworkFactory.builder().connectString(ts.getConnectString()).retryPolicy(new ExponentialBackoffRetry(1000, 5)).build();
>     curator.start();
>     curator.getZookeeperClient().blockUntilConnectedOrTimedOut();
>     curator.create().creatingParentsIfNeeded().forPath("/parent", "A string".getBytes());
>     
>     try {
>       LeaderLatch ll = new LeaderLatch(curator, "parent", "myNode");
>       ll.start();
>       ll.await();
>       System.out.println(ll.hasLeadership());
>       ll.close();
>     } catch (Exception e) {
>       e.printStackTrace();
>     }
>     ts.close();
>   }
> {code}
> the system will just hang forever. Inspecting the TestingServer with zkcli shows entries showing up though.
> If I switch out the path in the LeaderLatch constructor with "/parent", the same path is created AND the program runs fine.
> LeaderLatch should either accept the path all around or fail outright, not this half state that makes things difficult for the user.


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