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

roundrobin: strip attributes from addresses #4024

Merged
merged 6 commits into from Nov 30, 2020

Conversation

menghanl
Copy link
Contributor

attributes is stripped from addresses before they are used as map keys.
SubConns are still created with the original addresses (with attributes).

aNoAttrs := a
aNoAttrs.Attributes = nil
addrsSet[aNoAttrs] = struct{}{}
if _, ok := b.subConns[aNoAttrs]; !ok {
Copy link
Member

Choose a reason for hiding this comment

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

} else {
  sc.UpdateAddresses(a)
}

In case the attributes change in a meaningful way (to the transport/grpc).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@menghanl menghanl added no release notes Type: Behavior Change Behavior changes not categorized as bugs and removed no release notes labels Nov 10, 2020
@menghanl menghanl added this to the 1.34 Release milestone Nov 10, 2020
Comment on lines 133 to 134
// changed. This is a noop if the current address is the same as the
// old one (reflect.DeepEqual).
Copy link
Member

Choose a reason for hiding this comment

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

What does this mean? It shouldn't be a "true" nop. It should make it so these attributes are used if we ever need to reconnect.

Of course, we don't actually have any attributes that matter right now, besides the network type, which isn't something that it makes sense to change over time for the same address.

Maybe we should update the grpclb usage of Metadata for the server name to go through attributes instead so we can test this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If reflect.DeepEqual returns true, sc.UpdateAddresses would immediately return.
reflect.DeepEqual also compares the attributes, so this early return only happens when the new addresses is exactly the same as old.

This change has nothing to do with grpclb. And we will need changes in ClientConn to handle attributes.
That includes making the attributes hashable (or comparable?), and distinguish between the attributes that matter (for connection, e.g. creds), and those that only for balancers to use (e.g. hierarchy)

Copy link
Member

Choose a reason for hiding this comment

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

reflect.DeepEqual also compares the attributes

Oh, I see what you are saying here. My mistake.

This change has nothing to do with grpclb.

No, but that's an example of a potential attribute that could affect the transport, besides network type. Changing it would allow us to test the change you just made. Actually, we could also implement a dummy handshaker to read the attributes and verify they were updated when a reconnect happens.

What I was thinking was:

  1. Push an address from the resolver with no attributes
  2. Connect
  3. Push the same address from the resolver but with new attributes
  4. Force disconnect/reconnect
  5. Verify new attributes are in use

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a test

// changed. This is a noop if the current address is the same as the
// old one (reflect.DeepEqual).
//
// TODO: delete this when this balancer reads attributes.
Copy link
Member

Choose a reason for hiding this comment

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

This is what Java does now. It's unclear if we should be trying to be more aggressive about forcing a reconnect to pick up the new attributes if we know they changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When we know how to hash attributes, and know which part of it matters for connections, it will be easier to decide a UpdateAddresses is needed. And the SubConn would decide if it will reconnect to pick up the new attributes.

Copy link
Member

Choose a reason for hiding this comment

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

will be easier to decide a UpdateAddresses is needed

Right -- my point is we will still need to call UpdateAddresses in that case, so we won't be deleting this.

Copy link
Member

Choose a reason for hiding this comment

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

I would still say we should delete the TODO. We will update the addresses when the attributes change in a meaningful way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@dfawley dfawley assigned menghanl and unassigned dfawley Nov 12, 2020
@menghanl menghanl modified the milestones: 1.34 Release, 1.35 Release Nov 17, 2020
@menghanl menghanl assigned dfawley and unassigned menghanl Nov 19, 2020
@menghanl menghanl force-pushed the roundrobin_strips_attributes branch 3 times, most recently from 8227351 to 469a7d0 Compare November 19, 2020 01:26
balancer/roundrobin/roundrobin_test.go Show resolved Hide resolved
if len(md1) != 0 {
t.Fatalf("got md: %v, want empty metadata", md1)
}
case <-time.After(time.Microsecond * 100):
Copy link
Member

Choose a reason for hiding this comment

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

It's unclear which case is desired. Is this expected? If so we should Fatal always above, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made the above always fatal.

@dfawley dfawley assigned menghanl and unassigned dfawley Nov 19, 2020
@menghanl menghanl assigned dfawley and unassigned menghanl Nov 20, 2020
@dfawley dfawley assigned menghanl and unassigned dfawley Nov 20, 2020
…esses

`attributes` is stripped from addresses before they are used as map keys.
SubConns are still created with the original addresses (with attributes).
@menghanl menghanl merged commit 4a0125a into grpc:master Nov 30, 2020
@menghanl menghanl deleted the roundrobin_strips_attributes branch November 30, 2020 22:20
davidkhala pushed a commit to Hyperledger-TWGC/grpc that referenced this pull request Dec 7, 2020
@lemonlinger
Copy link

lemonlinger commented Feb 28, 2021

Sad.... we implemented a custom resolver and picker to support load balancing by weight saved in resolver.Address.Attributes. When the picker was generated, it read weights from SubConnInfo.Address whose Attributes were stripped. Now our picker doesn't work properly.

@dfawley
Copy link
Member

dfawley commented Mar 1, 2021

@lemonlinger you may want to fork the base balancer at a version that was working for you. This is a problem with the way the base balancer is designed IMO. #3425

// Note that this doesn't handle the case where the attribute content is
// different. So if users want to set different attributes to create
// duplicate connections to the same backend, it doesn't work. This is
// fine for now, because duplicate is done by setting Metadata today.

Choose a reason for hiding this comment

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

Hello @menghanl , we were using attributes to create duplicate connections to our backend because Metadata is deprecated. Is the current advice to use this deprecated API in order to create duplicate backend connections?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. Please use the deprecated Metadata field (it should be pretty stable, there's no plan to delete it). Sorry for the trouble.

Choose a reason for hiding this comment

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

We're looking forward to when the attributes can be used for this again. Thanks for the reply!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Behavior Change Behavior changes not categorized as bugs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants