bneradt commented on PR #11143: URL: https://github.com/apache/trafficserver/pull/11143#issuecomment-1984598831
> I still don't understand the problematic case. Are you saying write_time_threshold is not working? Yes, sorry if I wasn't clear. To be concise: Without this patch, write_size_threshold can hold up a frame, but write_time_threshold (default of 100ms) is not functionally, or at least not consistenly, taking place. The new autest demonstrates this by sending thousands of small DATA frames, one every ms. The server should get chunks of data at least every write_size_threshold (set to 10ms for the test). Instead, without this patch, it gets a DATA frame or a few at the beginning, then none of the rest till the end. > As long as WRITE_READY event is issued appropriately, the data in the buffer should be flushed even without END_STREAM flag at the end. > > A possible bug is that WRITE_READY is not scheduled for some reason. Maybe reenable() is not called. Calling flush in the new retransmit event will call reenable. Adding this event scheduled in `write_time_threshold` guarantees that reenable will be called via flush. The new event seems like a consistent way to guarantee that the data gets flushed in the appropriate amount of time, within write_time_threshold. But if there's a better way to accomplish this without the event, I'm definitely open to that. Why is the WRITE_READY event guaranteed to be triggered presently about write_time_threshold ms after write_size_threshold holds up a packet? Currently that doesn't happen, but maybe there's something I can do to address that? -- 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: github-unsubscr...@trafficserver.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
