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

Fix bug with watch handlers not being closed upon consul reload #3186

Closed
wants to merge 3 commits into from

Conversation

preetapan
Copy link
Contributor

@preetapan preetapan commented Jun 23, 2017

Prior to 0.8.4, when "consul reload" was executed, any existing watch handlers were stopped via the Stop method. When things moved around, this broke in a way that only the first "consul reload" would do the right thing. Subsequent "consul reloads" would never find the new watch handlers because the reference to agent.config is always the first one.

My fix is the smallest possible change that works, because I want to get this in for the Tuesday release. I am still in favor of separating watch behavior from watch configuration so that this sort of stuff doesn't have to hang off agent.Config.

magiconair and others added 2 commits June 23, 2017 15:34
This patch fixes watch registration through the config file
and a broken log line when the watch registration fails.

Fixes #3177
@preetapan
Copy link
Contributor Author

@slackpad I based this off @magiconair 's fix in #3181, since watch handlers need to be registered first for this bug to show up. You'll have to merge his fix first before this one, or you can get both in if you merge this PR.

@preetapan preetapan requested review from slackpad and magiconair June 23, 2017 22:45
@preetapan preetapan changed the title Fix watch handler regression Fix bug with watch handlers not being closed upon consul reload Jun 23, 2017
Copy link
Contributor

@slackpad slackpad left a comment

Choose a reason for hiding this comment

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

One thing to fix and one general comment, otherwise LGTM. I'll merge this to include @magiconair's change.

@@ -118,3 +118,7 @@ func (p *Plan) shouldStop() bool {
return false
}
}

func (p *Plan) IsStopped() bool {
return p.stop
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like it needs to take the stopLock

if err != nil {
errs = multierror.Append(errs, fmt.Errorf("Failed to determine HTTP address: %v", err))
}

// Deregister the old watches
for _, wp := range a.config.WatchPlans {
for _, wp := range prevConfig.WatchPlans {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we might want to eventually keep these on the agent itself and call a.unloadWatches() here, so we don't need to pass the old config, but this is a more minimal change so probably better for Tuesday.

@magiconair
Copy link
Contributor

I think if we move the WatchPlans out of the Config and into the agent and have a loadWatches and unloadWatches or just reloadWatches function which unloads and loads watches we avoid most of the issues and the change isn't bigger but we'll do it right instead of patching around. Since @preetapan added a test I'd prefer to focus on this. I can then drop the ProtoAddr as a cleanup later.

@slackpad
Copy link
Contributor

@magiconair yeah that works for me - it's really just keeping a slice on the agent.

@slackpad slackpad deleted the fix-watch-handler-regression branch August 8, 2017 18:36
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