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

Improve event loop locality of client requests #11300

Open
wants to merge 10 commits into
base: 4.8.x
Choose a base branch
from
Open

Conversation

yawkat
Copy link
Member

@yawkat yawkat commented Nov 1, 2024

If a request is made on an event loop that is part of the same event loop group that the client is configured to use, prefer making the connection on that same event loop. This keeps all the relevant processing on the same thread and may improve performance.

Also adds cancellation support to ExecutionFlow.
Implement "proper" context propagation in the client to get rid of the old ClientServerContextFilter.

Because context propagation uses its own key for the reactor context instead of ServerRequestContext.KEY, I've deprecated ServerRequestContext.KEY and added a more general API that can use the propagated context from the ContextView.
- In toPublisher, return a specialized FlowAsMono that (a) directly extends Mono so does not need a reactor wrapper and (b) supports SYNC fusion so that when the flow completes after the toPublisher call but before subscribe, we can take advantage of reactor fusion operations.
- Introduce a new method fromPublisherEager that can unwrap FluxAsMono directly (to short-circuit the direct ExecutionFlow->Publisher->ExecutionFlow transform) but can also transform Monos that complete immediately (e.g. Mono.just(…).map(…)) directly to ImperativeExecutionFlow.
If a request is made on an event loop that is part of the same event loop group that the client is configured to use, prefer making the connection on that same event loop. This keeps all the relevant processing on the same thread and may improve performance.
@yawkat yawkat added the type: improvement A minor improvement to an existing feature label Nov 1, 2024
@yawkat yawkat added this to the 4.8.0 milestone Nov 1, 2024
Base automatically changed from reactor-opts to 4.8.x November 14, 2024 14:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: improvement A minor improvement to an existing feature
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

2 participants