shinrich commented on code in PR #9366:
URL: https://github.com/apache/trafficserver/pull/9366#discussion_r1145388843
##########
proxy/http2/Http2ConnectionState.cc:
##########
@@ -1790,19 +2090,20 @@ Http2ConnectionState::send_a_data_frame(Http2Stream
*stream, size_t &payload_len
}
if (stream->is_write_vio_done()) {
+ Http2StreamDebug(this->session, stream->get_id(), "End of Data Frame");
flags |= HTTP2_FLAGS_DATA_END_STREAM;
}
// Update window size
- this->decrement_peer_rwnd_in(payload_length);
+ this->decrement_peer_rwnd(payload_length);
stream->decrement_peer_rwnd(payload_length);
// Create frame
- Http2StreamDebug(session, stream->get_id(), "Send a DATA frame - client
window con: %5zd stream: %5zd payload: %5zd",
- _peer_rwnd_in, stream->get_peer_rwnd(), payload_length);
+ Http2StreamDebug(session, stream->get_id(), "Send a DATA frame - peer window
con: %5zd stream: %5zd payload: %5zd flags: 0x%x",
+ _peer_rwnd, stream->get_peer_rwnd(), payload_length, flags);
Http2DataFrame data(stream->get_id(), flags, resp_reader, payload_length);
- this->session->xmit(data, flags & HTTP2_FLAGS_DATA_END_STREAM);
+ this->session->xmit(data);
Review Comment:
So flushing always gives us correctness in the presence of the more
sophisticated flow control options? Without the flush, the performance
optimization of flushing less frequently causes stalls?
Sounds like the time-based flush logic doesn't work in with the more
sophisticated flow control options. Perhaps we stick with the correct logic
for this PR, and fix the performance optimization in another PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
