bryancall opened a new pull request, #14004:
URL: https://github.com/apache/trafficserver/pull/14004
The chunked_passthru_flow_control, chunked_h1_flow_control and
chunked_h2_flow_control Uranium tests fail intermittently on 9.2.x CI
with "Metric proxy.process.http.tunnel.chunked_throttle was 0" or
"Could not read metric". They have failed this way on #13892, #13938,
#13978 and #13981.
On 9.2.x these tests run ATS under traffic_manager, so traffic_ctl reads
traffic_manager's copy of the metric. traffic_server publishes it
through two independent five-second timers: the raw-stat sync that sums
the per-thread counts, then the remote sync that pushes changed records
to traffic_manager. The value can trail the throttle by about ten
seconds, but the default metric check gives up after twelve (a 2 second
delay plus a 10 second poll). Under load the syncs slip past that window
even though the throttle fired. Master is not affected because
traffic_ctl reads the metric from traffic_server directly there.
This patch polls for 60 seconds with no initial delay, as remap_stats
already does for the same reason. A run in which the throttle never
fires still fails with "was 0".
Testing, in the fedora:45 CI image with ten containers running the
three tests in a loop under CPU load, 600 test runs each:
- Before: 21 metric failures. Every failing run logged the throttle's
"disable ... read_vio" debug line, so the counter had been bumped.
- After: 0 metric failures.
- With default_buffer_water_mark raised so the throttle cannot fire,
all three tests still fail with "was 0" after about 65 seconds.
--
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]
