Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Sat, 30 Apr 2016 19:20:12 +0000 (UTC)
From: "Jordan Zimmerman (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12962942.1461749306000.79107.1462044012847@Atlassian.JIRA>
In-Reply-To: <JIRA.12962942.1461749306000@Atlassian.JIRA>
References: <JIRA.12962942.1461749306000@Atlassian.JIRA>
 <JIRA.12962942.1461749306706@arcas>
Subject: [jira] [Commented] (CURATOR-318) Threads may return different
 boolean values when entering same double barrier
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jordan Zimmerman commented on CURATOR-318:
------------------------------------------

I ran the test but I have no idea what I'm looking at. Please re-write the test as a TestNG unit test with an asserts, etc. that show the problem. You can use the examples of the copious Curator tests.

> Threads may return different boolean values when entering same double barrier
> -----------------------------------------------------------------------------
>
>                 Key: CURATOR-318
>                 URL: https://issues.apache.org/jira/browse/CURATOR-318
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.10.0
>            Reporter: Shiliang Cao
>            Priority: Critical
>         Attachments: DoubleBarrierTimeoutTest.java
>
>
> To my understanding, when all threads are trying enter an barrier, they should all success or fail, which means their return values should be the same.
> But actually they may get different return values in this situation (reproduce steps):
> 0. Some preparing works such as running a zk server, basic curator connecting codes;
> 1. Prepare 3 threads: thread1/ thread2/ thread3;
> 2. Thread1 sleep 20 seconds then enter barrier, thread2 and thread3 try to enter barrier right now, with timeout value set to 5 seconds;
> 3. Result: thread2 and thread3 returned false due to timeout as expected, but thread1 (the sleeping one) just return true, which I think should be false too.
> Possible root cause as I observed via zkCli:
> When thread1 and thread2 enter methods returned, their path nodes remained, so when thread3 came, it just think other threads are still waiting, so it just created the ready node and return with true.
> If this is not by design, it should be a design defect.


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