[PATCH] Added keepalive_async_fails command

Maxim Dounin mdounin at mdounin.ru
Mon Apr 3 01:42:21 UTC 2023


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.carter at 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/


More information about the nginx-devel mailing list