Connection retaining mode for p2p peer chooser #6471
Merged
Conversation
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
taylanisikdemir
force-pushed
the
taylan/p2p_retain
branch
from
9487ada to
89e0870
Compare
taylanisikdemir
requested review from
Shaddoll,
neil-xie,
davidporter-id-au,
Groxx,
shijiesheng,
jakobht,
3vilhamster,
sankari165,
dkrotx and
demirkayaender
as code owners
Shaddoll
reviewed
Nov 12, 2024
Shaddoll
reviewed
Nov 12, 2024
Shaddoll
reviewed
Nov 12, 2024
Shaddoll
reviewed
Nov 12, 2024
taylanisikdemir
force-pushed
the
taylan/p2p_retain
branch
from
16710bb to
03318db
Compare
Shaddoll
approved these changes
Nov 12, 2024
| return c.Start() | ||
| } | ||
|
|
||
| return fmt.Errorf("failed to start direct peer chooser because direct peer chooser initialization failed, err: %v", g.legacyChooserErr) |
| ) | ||
|
|
||
| const ( | ||
| defaultGRPCSizeLimit = 4 * 1024 * 1024 | ||
| factoryComponentName = "rpc-factory" | ||
| ) | ||
|
|
||
| var ( | ||
| // P2P outbounds are only needed for history and matching services | ||
| servicesToTalkP2P = []string{service.History, service.Matching} |
There was a problem hiding this comment.
Is frontend --> History not in scope? I can see a strong case for having frontend retain connections to history and matching instances as peers?
There was a problem hiding this comment.
I also think that worker might need need membership updates for the domain config stack (@Shaddoll can correct me)
There was a problem hiding this comment.
These are sharded services that all other services communicate via p2p connections. RPC factory subscribes to membership updates of these services for that reason. Frontend and worker will still use this rpc factory and will be able to communicate with matching&history via p2p
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What changed?
This PR is continuation of PR #6345 to complete implementation of custom peer chooser.
The custom chooser differs from yarpc's default "direct" chooser in how it handles connections. Direct chooser creates & releases p2p connections for each request.
The new peer chooser retains connections until the peer disappears from member list. Peers are added as needed basis (when a request is about to be made to a target peer).
There's going to be one peer chooser instance per target service which will cache active peers internally.
Only matching and history are such target services that all other services communicate p2p.
This is hidden behind feature flag
system.enableConnectionRetainingDirectChooserand yarpc's direct peer chooser will still be used by default.Other changes:
Why?
Avoid unnecessary cost of recreating connections for each p2p request.
How did you test it?