[
https://issues.apache.org/jira/browse/CURATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927888#comment-15927888
]
J D commented on CURATOR-233:
-----------------------------
I have created a fix for the original bug submitted in July 2015. However, the
bug fix necessitates that the shortcut described in
http://zookeeper.apache.org/doc/r3.1.2/recipes.html#sc_doubleBarriers is
removed (see also comment from 26/Aug/15 15:04). So more messages are exchanged
now for the second barrier.
Regarding the question of Shiliang Cao:
Currently, some clients leave the second barrier early due to timeouts, they
return false. And all remaining clients leave the second barrier only after all
remaining clients have reached the second barrier, they return true.
I guess the question of Shiliang Cao is whether all clients should return the
same: All clients return false if at least one client has timed out, otherwise
all clients return true.
I think both options can make sense.
Best regards, J D
> Bug in double barrier
> ---------------------
>
> Key: CURATOR-233
> URL: https://issues.apache.org/jira/browse/CURATOR-233
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 2.8.0
> Reporter: J D
> Assignee: Mike Drob
> Fix For: TBD
>
> Attachments: DoubleBarrierClient.java, DoubleBarrierTester.java
>
>
> Hi,
> I think I discovered a bug in the internalLeave method of the double barrier
> implementation.
> When a client is told to leave the barrier after maxWait it does not do so. A
> flag is set but the client does not leave the barrier, instead it keeps
> iterating through the control loop and drives CPU usage to 100%.
> I have attached an example.
> Best regards
> Lianro
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
