-
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
grpc: support channel idleness #6263
Merged
Merged
Changes from 17 commits
Commits
Show all changes
21 commits
Select commit
Hold shift + click to select a range
bb51629
grpc: support channel idleness
easwars 968a05f
call cc.Connect only when IDLE at blocking dial time
easwars fe30e55
support an atomic idleness manager
easwars 1693446
align 64-bit fields for proper atomic access
easwars 0b2a531
make vet happy
easwars 87ae17b
implement Doug's suggestion
easwars 32875a1
minor fix + access timer under lock
easwars 5c6910e
also check acitivty in tryEnterIdleMode
easwars fa1a004
skip error log when calls count is negative in onCallEnd
easwars 2b04a5b
create and destroy resolver wrapper instead of supporting idleness in it
easwars 0748ab4
start channel in idle, and kick it out of idle at the end of Dial
easwars 93c990e
review comments + remove mutexIdlenessManager
easwars a0eaa5c
reset ccb.curBalancerName when exiting idle
easwars 37c286a
remove the mutex idleness manager from tests
easwars 0682572
todo to switch balancer/picker wrappers to the same approach as resol…
easwars 460400c
remove unused consts
easwars f13ba8a
reset ccb.curBalancerName when entering idle instead of when exiting …
easwars 2068ba0
refactor new idleness manager to hide implementation details
easwars d69513f
defer the call to onCallEnd()
easwars f1f091a
test cleanups
easwars f94f923
handle small flake by trying the RPC more frequently
easwars 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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -27,14 +27,22 @@ import ( | |
// | ||
// All errors returned by Invoke are compatible with the status package. | ||
func (cc *ClientConn) Invoke(ctx context.Context, method string, args, reply interface{}, opts ...CallOption) error { | ||
if err := cc.idlenessMgr.onCallBegin(); err != nil { | ||
return err | ||
} | ||
|
||
// allow interceptor to see all applicable call options, which means those | ||
// configured as defaults from dial option as well as per-call options | ||
opts = combine(cc.dopts.callOptions, opts) | ||
|
||
var err error | ||
if cc.dopts.unaryInt != nil { | ||
return cc.dopts.unaryInt(ctx, method, args, reply, cc, invoke, opts...) | ||
err = cc.dopts.unaryInt(ctx, method, args, reply, cc, invoke, opts...) | ||
} else { | ||
err = invoke(ctx, method, args, reply, cc, opts...) | ||
} | ||
return invoke(ctx, method, args, reply, cc, opts...) | ||
cc.idlenessMgr.onCallEnd() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Optional: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. |
||
return err | ||
} | ||
|
||
func combine(o1 []CallOption, o2 []CallOption) []CallOption { | ||
|
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.
This should only happen if a balancer that was already
Closed
calls, right?If so, I think we should
logger.Error
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.
This is making me think...
What happens if an LB policy (or resolver; I haven't looked at
resolver_conn_wrapper.go
yet) is closed due to entering idle, then the channel exits idle, and then the old LB policy (or resolver) makes calls on theClientConn
. It seems we need to either create new wrappers instead of reusing the existing ones, OR we need to ensure thatccb.balancer == <the balancer calling us but I don't know how we could even check this>
, OR we need to make accBalancerWrapperWrapper
that is invalidated when the LB policy is closed (this is hopefully not a serious suggestion).Especially since we delay closure by calling it in a goroutine, it seems like this is a very real possibility.
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.
Based on our offline discussion, I switched the resolver wrapper to be closed on entering idle and recreated upon exiting idle.
But for the balancer and picker wrappers, I left it as is, i.e with methods to enter and exit idle. For the balancer wrapper, once the underlying balancer is closed, the graceful switch balancer (which is always our top-level balancer) will take care of dropping calls from the old (and closed) LB policy.
Also, for the balancer and picker wrappers, it is not be easy to close and recreate them because that would mean that all accesses to them would need to be guarded with
cc.mu
. This is not possible because the picker wrapper needs to be accessed at pick time, while the balancer wrapper needs to be accessed whenever there is a subConn state change and whencc.Connect
is called.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 was thinking the picker wrapper would be safe to access, since you would do so only after going through the idleness manager, which should ensure that the picker wrapper exists before returning. And a mutex around balancer accesses doesn't seem too troublesome. It would be nice to handle these two subcomponents the same way, but I'm fine with this approach if it's working and gets us idleness working.
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 agree that it would be nicer to follow the same approach with the other two wrappers. But given that I'm constrained for time at this point, I have left a TODO for the same.