[
https://issues.apache.org/jira/browse/CURATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14709692#comment-14709692
]
Mike Drob commented on CURATOR-233:
-----------------------------------
Ah, I think I see what you are saying. I did not read the client closely enough
the first time.
I have pushed some changes to the test:
https://github.com/madrob/curator/commit/d73cbe703d9909c49c5cf840a240bca83ab4f041#diff-557f6b53f4b9e30b2abc3199b692f0acR286
I noticed that when I store the result from the leave method, then the client
does leave when it is supposed to. When I do not store the result, then the
client waits to leave like you have noticed. This is a very strange behaviour
to see...
Also, when examining the result, I noticed that returning early seems to still
give 'true' which conflicts with what the javadoc advertises. I will look into
that deeper.
> 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
> Fix For: awaiting-response
>
> 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.4#6332)
