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

grpclb: support "pick_first" child policy #5438

Merged
merged 17 commits into from Mar 6, 2019

Conversation

zhangkun83
Copy link
Contributor

The PICK_FIRST mode puts all backend addresses in a single Subchannel. There are a few points where it's different from the default ROUND_ROBIN mode:

  1. PICK_FIRST doesn't eagerly connect to backends like ROUND_ROBIN does. Instead, it requests for connections when the Subchannel is picked.
  2. PICK_FIRST adds tokens to the headers via a different code path (TokenAttachingTracerFactory) than ROUND_ROBIN
  3. For simple implementation, when the mode is changed by service config when the LoadBalancer is working, we will shut down GrpclbState and starts a new one with the new mode. All connections will be closed during the transition. We don't expect this to happen in practice given the specific use case of PICK_FIRST.

PickResult picked(Metadata headers);
}

@VisibleForTesting
static final class BackendEntry implements RoundRobinEntry {
final Subchannel subchannel;
Copy link
Member

Choose a reason for hiding this comment

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

Why is this being stored now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because it's always non-null in BackendEntry, and there are quite a few places that need to retrieve the subchannel from BackendEntry. entry.subchannel is easier to reason than entry.result.getSubchannel() that you won't get a null.

@zhangkun83 zhangkun83 merged commit 2f50d88 into grpc:master Mar 6, 2019
@zhangkun83 zhangkun83 deleted the grpclb_pickfirst_3 branch March 6, 2019 21:02
@lock lock bot locked as resolved and limited conversation to collaborators Jun 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants