Hello! On Sun, Apr 02, 2023 at 06:57:03PM +0100, J Carter wrote:
> I've also attached an example nginx.conf and test script that > simulates the asynchronous close events. > Two different test cases can be found within that, one with path > /1 for single peer upstream and /2 for multi-peer. > > You should see 2 upstream addresses repeated in a row > per-upstream-server in the access log by default, as it fails > through the cached connections & next performs next upstream > tries. > > Any feedback would be appreciated. > > # HG changeset patch > # User jordanc.car...@outlook.com > # Date 1680457073 -3600 > # Sun Apr 02 18:37:53 2023 +0100 > # Node ID 9ec4d7a8cdf6cdab00d09dff75fa6045f6f5533f > # Parent 5f1d05a21287ba0290dd3a17ad501595b442a194 > Added keepalive_async_fails command to keepalive load balancer module. > This value determines the number suspected keepalive race events > per-upstream-try that will be tolerated before a subsequent network connection > error is considered a true failure. It looks like you are trying to address issues with re-trying requests to upstream servers when errors not distinguishable from asynchronous close events happens, as outlined in ticket #2421 (https://trac.nginx.org/nginx/ticket/2421). I don't think that introducing another directive for this is a good idea. Rather, I would consider modifying the behaviour to better behave in case of such errors. In particular, the following approaches look promising: - Allow at most one additional try. - Allow an additional try only if there is a single peer, so normally request is not going to be retried at all. - Don't use cached connections if an error considered to be an asynchronous close event happens. Given that since nginx 1.15.3 we have keepalive_timeout in the upstream blocks to mitigate potential asynchronous close events, even something simple like combination of (1) and (2) might be good enough. With (3), things are going to be as correct as it can be. [...] -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-devel
