[PATCH 4 of 4] AIO operations now add timers (ticket #2162)

[J Carter]

On Mon, 8 Jan 2024 11:25:55 +0000
J Carter <jordanc.carter at outlook.com> wrote:

> Hello,
> 
> On Mon, 27 Nov 2023 05:50:27 +0300
> Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > # HG changeset patch
> > # User Maxim Dounin <mdounin at mdounin.ru>
> > # Date 1701050170 -10800
> > #      Mon Nov 27 04:56:10 2023 +0300
> > # Node ID 00c3e7333145ddb5ea0eeaaa66b3d9c26973c9c2
> > # Parent  61d08e4cf97cc073200ec32fc6ada9a2d48ffe51
> > AIO operations now add timers (ticket #2162).
> > 
> > Each AIO (thread IO) operation being run is now accompanied with 1-minute
> > timer.  This timer prevents unexpected shutdown of the worker process while
> > an AIO operation is running, and logs an alert if the operation is running
> > for too long.  
> 
> Shouldn't this timer's duration be set to match worker_shutdown_timeout's
> duration rather than being hard coded to 60s ?

Ah nevermind, I understand.

These timers will either expire from passing the 60s set duration, or 
will expire as worker_process_timeout itself expires, kills the 
connection and times out associated timers (including the aio timers). 

Setting it to worker_shutdown_timeout's duration would be pointless 
(an 'infinite' timer would give the same result).

So the only situation in which a different value for these AIO 
timers would make sense is if these AIO operations are expected to
take longer 60s, but less than worker_shutdown_timeout (in cases 
where it has been increased from it's own default of 60s).

In that case the AIO operation's timeout would have to be one 
(or more) of it's own directives, with a value less than 
worker_shutdown_timeout. 

(doesn't seem like it's worth it from the ticket discussion,
sorry for the noise).


> > This fixes "open socket left" alerts during worker processes shutdown
> > due to pending AIO (or thread IO) operations while corresponding requests
> > have no timers.  In particular, such errors were observed while reading
> > cache headers (ticket #2162), and with worker_shutdown_timeout.  
> 
> [...]