Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplified barrier logic #127

Merged
merged 11 commits into from
Jul 10, 2015
Merged

Simplified barrier logic #127

merged 11 commits into from
Jul 10, 2015

Conversation

marcusking01
Copy link
Contributor

Made the logic for how we await on a state barrier easier.

The client first creates/joins the barrier in a blocking call. Afterwards we kick off a go routine that loops with a zkwatcher on the barrier zkNode and doesn't notify the AwaitOnStateBarrier func until either it sees all expected clients or gets an error.

select {
case <-zkMemberJoinedWatcher:
continue
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this select also have a case <-stopChan? It looks it might block here indefinitely

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good thinking. I've added the case <- stopChan on the inner select statement.

Marcus and others added 4 commits July 1, 2015 09:51
// Haven't seen all expected consumers on this barrier path. Watch for changes to the path...
select {
case <-stopChan:
return
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suppose we should have that blackhole function to read from zkMemberJoinedWatcher here as well. Consider a following case: we create a zkMemberJoinedWatcher and hit the barrier timeout; the stopChan receives a value but then a member joins; zk lib tries to write to zkMemberJoinedWatcher but no one listens to it anymore. At this point zk lib would probably block indefinitely.

edgefox added a commit that referenced this pull request Jul 10, 2015
@edgefox edgefox merged commit 040f411 into elodina:master Jul 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants