-
Notifications
You must be signed in to change notification settings - Fork 4.7k
internal/delegatingresolver: avoid proxy if networktype of target address is not tcp #8215
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
Merged
Merged
Changes from 17 commits
Commits
Show all changes
35 commits
Select commit
Hold shift + click to select a range
751dd5e
no proxy if not tcp
eshitachandwani 4476246
endpoint check
eshitachandwani 39d3ded
passing tests
eshitachandwani fcbc507
test
eshitachandwani 618877a
correct test
eshitachandwani d150d8e
Merge branch 'master' into d_error
eshitachandwani 325e8cb
merge conflicts
eshitachandwani f2a6133
check
eshitachandwani 8742ea7
var change
eshitachandwani 607ec91
var change
eshitachandwani d254b04
refactor
eshitachandwani cfe7e4f
comments
eshitachandwani e8e8438
comments
eshitachandwani b941b53
proxy resolver
eshitachandwani fc393ba
remove bool
eshitachandwani 00c62de
make channel buffered
eshitachandwani a98a62f
make channel buffered
eshitachandwani 2d449cb
fix non tcp after tcp
eshitachandwani 0f831a1
rough
eshitachandwani aa60db2
correct test
eshitachandwani 854daca
correct test
eshitachandwani d4942ba
correct test
eshitachandwani 821475e
correct test
eshitachandwani a3fa521
refactor
eshitachandwani 9b384af
refactor
eshitachandwani 8f157d8
blank line
eshitachandwani 94c1f47
blank line
eshitachandwani 7c5ad78
test
eshitachandwani 1aa9f1c
test
eshitachandwani 0049fa9
minor changes
eshitachandwani bf57c2c
assignment
eshitachandwani 6e77ff3
minors
eshitachandwani fa78c83
minor
eshitachandwani 1679375
goroutine order comment
eshitachandwani 0a50ca5
comment
eshitachandwani 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 hidden or 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
Oops, something went wrong.
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.
I don't think we need a channel here, instead we can have a bool named something like
proxyResolverInitializedand have it protected bychildMu. We're acquiringchildMuto accessproxyResolveranyways, we can rely on the mutex for synchronization.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.
I think we do , the most prominent use case being when
ResolveNowis called beforeUpdateState. In that case , we want that proxy resolver is built first ( called in targetResolver'sUpdateState) beforeresolveNowfor proxy resolver is called. And in that case we need an order, but using mutex, we cannot define the order in which the actions might execute , we also want to block until proxyResolver is built. So I think using channel is more appropriate. Is there a preference using channels or variables with mutexes?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.
If
ResolveNowis called by the channel before the firstUpdateStatecall comes from the resolver, then I think we can safely ignore it. Or maybe I'm not understanding the situation you're describing. It would be helpful to list clear operations and their orders for things like this.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.
Right! that was the question because the recent test introduced was calling
ResolveNowjust after delegating resolver is built and we have now changed the policy for creating proxy resolver only on target resolver update