-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Make RPC limits reloadable #4216
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
255492b
add unit tests: limits configuration should be reloadable
jwasinger 672a2a3
agent: reload limits upon restart
jwasinger 65746b2
Apply the limits to the clients rpcLimiter
mkeeler 0f5798f
Update docs about rpc limits being reloadable
mkeeler 08e26d1
Merge branch 'master' of github.com:hashicorp/consul into rpc-limiting
mkeeler 0df7cd2
Add a Client ReloadConfig test
mkeeler 40e6d9c
Fixup a weird merge problem
mkeeler File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all looks good to me but I wonder if we should have 3 different goroutines all spawn and run this in a loop and verify that
go test -race
doesn't pick up any concurrency issues?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ReloadConfig can't be called concurrently. At least as the code stands today.
Client.ReloadConfig is only called from Agent.ReloadConfig which in turn is only called from cmd.handleReload (command/agent/agent.go) and finally handleReload is only called from a loop in cmd.run which is processing the chan of signals. As it can only handle 1 signal at a time, ReloadConfig can therefore not be called concurrently so there can be no race. I have no doubt that if it was called concurrently there would be several problems (like watches, services etc could be loaded multiple times)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh OK. Maybe I confused the calls, I was mostly wanting to validate the
atomic.Value
stuff - I guess that is about calling this concurrently with RPC client reading the values so perhaps the valid test would be to start a goroutine (or 10) making RPCs while calling this in a loop or something.It's not a blocker, it just might be an extra sanity check that there aren't any obvious concurrency issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would that really test? To me it looks like that would be testing that atomc.Value.(Load/Store) do what they say they do. And since that is an upstream library (and builtin to the language) I would say that testing that is outside the scope of Consul testing and would only serve to lengthen test times. We should be able to assume that those atomic primitives work as expected. Because the whole limiter is now stored within the value it is impossible to access it without a load/store and since we don't do any write operations into an existing limiter during reload (but rather create a new limiter) there can be no race. Additionally the limiter looks to be thread safe in that if you did set new limits or perform other operations it will lock itself internally (which is how we can use one limiter with multiple go routines). Looks to be = I read through the code. I don't think they expressly say in the package documentation that this is the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's often the case that atomic values are misused. My suggestion was to guard against any of the common pitfalls of using them!
I don't think it's critical and agree the usage looks simple and correct so merge away but in general go's race detector is easy to use and can often catch subtle and common mistakes/bad assumptions in how
sync
primitives are used. 😄 .