On Thu, Feb 20, 2020 at 7:01 AM Pluem, Ruediger, Vodafone Group
<[email protected]> wrote:
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Eric Covener <[email protected]>
> > Gesendet: Donnerstag, 20. Februar 2020 12:33
> > An: Apache HTTP Server Development List <[email protected]>
> > Betreff: Re: KeepAliveTimeout vs. event issue
> >
> > > Or is it exactly the other way around? Does event close it after
> > > x s - 100 ms and hence earlier than announced?
> >
> > earlier then announced
>
> This is bad. Then we should add this back. If we keep it open a little bit
> longer (<= 1 s) it does not harm.
I think it it as simple as:
Index: server/mpm/event/event.c
===================================================================
--- server/mpm/event/event.c (revision 1874247)
+++ server/mpm/event/event.c (working copy)
@@ -1218,7 +1218,7 @@
* timeout today. With a normal client, the socket will be readable in
* a few milliseconds anyway.
*/
- cs->queue_timestamp = apr_time_now();
+ cs->queue_timestamp = apr_time_now() + TIMEOUT_FUDGE_FACTOR;
notify_suspend(cs);
/* Add work to pollset. */
To compensate for the fudge factor here that pushes timeout_time ahead:
/* We process the timeout queues here only when their overall next
* expiry (read once above) is over. This happens accurately since
* adding to the queues (in workers) can only decrease this expiry,
* while latest ones are only taken into account here (in listener)
* during queues' processing, with the lock held. This works both
* with and without wake-ability.
*/
if (timeout_time && timeout_time < (now = apr_time_now())) {
timeout_time = now + TIMEOUT_FUDGE_FACTOR;
/* handle timed out sockets */
apr_thread_mutex_lock(timeout_mutex);
/* Processing all the queues below will recompute this. */
queues_next_expiry = 0;
/* Step 1: keepalive timeouts */
if (workers_were_busy || dying) {
process_keepalive_queue(0); /* kill'em all \m/ */
}
else {
process_keepalive_queue(timeout_time);
}
