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

balancer: Add UpdateAddresses() to balancer.ClientConn interface #4215

Merged
merged 2 commits into from
Feb 25, 2021

Conversation

easwars
Copy link
Contributor

@easwars easwars commented Feb 18, 2021

This is the first PR for the set of API changes outlined in #4207.

This PR adds the UpdateAddresses() method to the balancer.ClientConn interface and changes gRPC code to use the new method instead of similarly named method on the SubConn interface.

@easwars easwars requested review from menghanl and dfawley February 18, 2021 16:46
@easwars easwars assigned easwars and dfawley and unassigned easwars Feb 18, 2021
@easwars easwars added the Type: API Change Breaking API changes (experimental APIs only!) label Feb 18, 2021
@easwars easwars added this to the 1.37 Release milestone Feb 18, 2021
@easwars easwars force-pushed the update_addresses_to_clientconn branch from 3c23e8d to 8006a39 Compare February 18, 2021 19:38
@menghanl menghanl assigned menghanl and unassigned dfawley Feb 18, 2021
@menghanl menghanl assigned easwars and dfawley and unassigned menghanl Feb 23, 2021
@easwars easwars force-pushed the update_addresses_to_clientconn branch from 8006a39 to 6f786bc Compare February 23, 2021 23:53
Comment on lines 172 to 177
ccb.mu.Lock()
if ccb.subConns == nil {
ccb.mu.Unlock()
return
}
ccb.mu.Unlock()
Copy link
Member

Choose a reason for hiding this comment

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

I think I asked about this before and you didn't know (?) -- why is this check here? It seems superfluous given the LB policy would have been calling UpdateAddresses directly previously.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After looking at the code a little bit more, I realized that this check is in all methods mainly to make sure that we do not process any of these calls once the balancer_wrapper is closed (which is done when the ClientConn is closed, or the LB policy is switched out). That is the reason why I let this stay. Let me know what you think.

Copy link
Member

Choose a reason for hiding this comment

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

Do we have similar checks in acbw.UpdateAddresses? If so, I'd omit this to keep it as minimal as possible. If not...why not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this is what is happening. addrConn is torn down when either the ClientConn is closed, or the balancer is switched out. And correspondingly addrConn has a state associated with itself.

Now, the existing methods of acBalancerWrapper, namely UpdateAddresses() and Connect() call into appropriate methods on the addrConn which eventually check the state of the addrConn, and if it is in Shutdown state, they end up doing nothing.

So, we should be safe to omit this check here and rely on the checks underneath. What do you think?

@dfawley dfawley removed their assignment Feb 24, 2021
@easwars easwars force-pushed the update_addresses_to_clientconn branch from fa900c0 to 7fa11f8 Compare February 25, 2021 23:40
@easwars easwars merged commit 9dfe677 into grpc:master Feb 25, 2021
@easwars easwars deleted the update_addresses_to_clientconn branch February 25, 2021 23:48
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: API Change Breaking API changes (experimental APIs only!)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants