bryancall opened a new pull request, #13874: URL: https://github.com/apache/trafficserver/pull/13874
The global and hybrid `pool_lock` tests sometimes get a 502 for one of their later sessions (#13871). That session finds the three connections allowed by `server_max_connections` already open, so it purges the pool and retries. The purge and the pool lookup only try the pool lock and give up if another thread holds it. A net thread that has just returned a connection to the pool holds that lock while it reads the connection, so if that thread is delayed right there, the purge and all three retries fail within microseconds, because `connect_attempts_retry_backoff_base` defaults to 0. The session then gets `502 Too many open files in system`. This sets `connect_attempts_retry_backoff_base` to 10 ms in the global and hybrid replays, so the retries are spread out and the purge runs once the lock is free. The single-thread replay is unchanged, because it checks that the purge happens right away. This is existing behavior, not something #13806 introduced: the same delay makes the test fail both before and after that change. Testing, in the fedora:44 CI image, with a build that holds the pool lock for a set time during that read: with a 200 µs hold, master fails 5 of 5 runs with the CI signature, and this change passes 30 of 30 runs at holds of 0, 200 µs and 1 ms. Without the added delay I could not reproduce the failure in over 400 runs, including under a one-CPU limit, which fits a rare stall on a busy CI agent. No backport: the `pool_lock` test is only on master. Fixes #13871 -- 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]
