bryancall opened a new pull request, #14002: URL: https://github.com/apache/trafficserver/pull/14002
The stats_over_http remap_intercept and compression tests reset a client connection after the first byte of a 1.6 MB prometheus response, then wait for the intercept to finish on EOS or ERROR. In CI they sometimes see `Intercept finished on VC_EVENT_WRITE_COMPLETE` instead and fail. Over loopback, Linux sizes the send buffer of Traffic Server's socket to the client at about 2.6 MB when the connection opens. That holds the whole body even though the client only takes in 4 KB, so when the client is slow to send its reset, as on a loaded CI host, the intercept finishes its write first. Enabling HTTP flow control does not help, because it bounds only the data buffered inside Traffic Server, not in the kernel. Both tests now set `proxy.config.net.sock_send_buffer_size_in` to 16 KB. Most of the body then stays in the intercept until the reset arrives, and the intercept finishes on ERROR as the tests expect. Each test was run 100 times on Fedora 44, with and without `stress-ng --cpu 32`: | | remap_intercept | compression | |---|---|---| | Before, no load | 0/100 | 0/100 | | Before, CPU load | 22/100 | 2/100 | | After, no load | 0/100 | 0/100 | | After, CPU load | 0/100 | 0/100 | Inside the fedora:44 CI container under the same load, remap_intercept failed 6/50 before and 0/50 after, and every reset in the fixed runs ended on ERROR. Every failure before the fix was the reset ending on WRITE_COMPLETE. The whole `pluginTest/stats_over_http/` directory passes with the change. On macOS the socket buffer already stays well under the body size, so the race does not arise there with or without the change. -- 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]
