Propagate explicit flushes through MessageFramer #323
Merged
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.
MessageFramer allows queing of data and explicit flushing. Sinks
generally can benefit from knowing when they are required to flush, so
we now tell them when MessageFramer received a flush so they only have
to flush when required.
This is an alternative to #313 which when combined with netty/netty#3670
would greatly decrease the number of TCP segments we send. The same
approach of this CL could be taken with headers to delay them if the request
is unary (which I think is already being done in OkHttp).
Note that this CL doesn't get all the gains we could. We currently do thread
synchronization in both OkHttp and Netty per-write. To optimize that we could
buffer in the sync until the flush arrives. This would allow combining header
writing into the same buffer. Alternatively, instead of the approach of this PR,
we could write batches of frames to the MessageFramer.Sink.
Note that all approaches discussed here aren't impacted by number of
messages being sent.