[
https://issues.apache.org/jira/browse/CURATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15928700#comment-15928700
]
J D commented on CURATOR-233:
-----------------------------
Hi Jordan,
the ZooKeeper recipe is correct. However, it is not compatible to clients that
have a maximum wait time and are allowed to leave the second barrier early when
that wait time has been reached.
The ZooKeeper recipe works as follows.
- Client 0 watches any other node (and leaves the barrier if only he is left)
- All other clients watch client 0 (and leave the barrier if client 0 has left)
So if you use the ZooKeeper recipe AND introduce a maximum wait time then:
- If any other client than client 0 leaves after maxWaitMs, nothing bad happens
and all remaining clients keep waiting
- But if client 0 leaves after maxWaitMs all other nodes leave together with
client 0 (even if they do not have a maxWaitMs time limit and should keep
waiting)
> 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)
