You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2022/01/21 11:18:34 UTC
[Bug 65832] New: purge keepalive connections before 0 idlers?
https://bz.apache.org/bugzilla/show_bug.cgi?id=65832
Bug ID: 65832
Summary: purge keepalive connections before 0 idlers?
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: enhancement
Priority: P2
Component: mpm_event
Assignee: bugs@httpd.apache.org
Reporter: covener@gmail.com
Target Milestone: ---
When event hits zero idlers, a keepalive connection that becomes active can be
abruptly closed in response to the new request being readable.
/* If we don't get a worker immediately (nonblocking), we
* close the connection; the client can re-connect to a
* different process for keepalive, and for lingering close
* the connection will be shutdown so the choice is to
favor
* incoming/alive connections.
*/
get_worker(&have_idle_worker, blocking,
&workers_were_busy);
if (!have_idle_worker) {
shutdown_connection(cs);
}
I don't know if normal browser requests will retry idempotent requests
transparently, but something like XHR will require error handling to do it.
It seems like if we are "approaching" zero idlers (and know that we have an
AsyncRequestWorkerFactor > 1) it would be better to shed some or all keepalive
connections earlier, before we have to shutdown ones that have just been used.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65832] purge keepalive connections before 0 idlers?
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65832
--- Comment #4 from Eric Covener <co...@gmail.com> ---
> This sounds (to me) like a more robust alternative, good/bad/off-topic idea?
I think it's a good idea. But I wonder if still we wouldn't want the preventive
aspect, otherwise we encourage stuff to be delayed in the pending_q which might
be tricky for debugging/observability.
Maybe preventive can be done without actively flushing idle keepalive
connections, for example with a low but non-zero supply of idlers considered in
connections_above_limit() to avoid adding fuel to the fire. But i am also not
excited about driving more flipping of disable_listensockets
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65832] purge keepalive connections before 0 idlers?
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65832
--- Comment #2 from Eric Covener <co...@gmail.com> ---
(In reply to Ruediger Pluem from comment #1)
> Confused now. My understanding is that only connections in keepalive will be
> stopped not ones that are in use. A client using a keepalive connection
> should be prepared that it gets closed. This cannot be handled gracefully
> always as non idempotent request if sent cannot be just resent. How would
> closing keepalives earlier improve the situation?
The one being closed in the snippet is closed shortly after the client has
reused it. IOW It's not simultaneous or a race, we're responding to activity on
the socket.
Closing them in advance (when the process has zero idlers) would be susceptible
to races / simultaneous close (of more sockets, assuming the server was going
to recover in time) but this kind of race is present on every timeout.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65832] purge keepalive connections before 0 idlers?
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65832
--- Comment #3 from Yann Ylavic <yl...@gmail.com> ---
I think that get_worker() should never block, it does not in this case and
there is no other choice than closing the connection (which is what we should
address IMHO).
We could try to be preventive here and kill kept-alive connections earlier
(when num_idlers < some threshold or alike?) as you propose, but this does not
address the blocking cases for WRITE_COMPLETION and PT_ACCEPT. If we had a
solution for these I think that the keepalive connection becoming active case
is not very different than the PT_ACCEPT case.
What we could do possibly in the listener when get_worker() (all nonblocking)
finds no worker is to:
1. disable_listensocks() so as not to make the situation worse
2. push those connections/sockets in a pending_q which workers would pop before
idling (like the defer_linger_chain)
3. maintain the pending_q with the other queues to kill the connections at some
point if no worker comes up soon enough (pathologically?)
4. teach should_enable_listensocks() about the pending_q to not recover too
early
This sounds (to me) like a more robust alternative, good/bad/off-topic idea?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 65832] purge keepalive connections before 0 idlers?
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65832
--- Comment #1 from Ruediger Pluem <rp...@apache.org> ---
Confused now. My understanding is that only connections in keepalive will be
stopped not ones that are in use. A client using a keepalive connection should
be prepared that it gets closed. This cannot be handled gracefully always as
non idempotent request if sent cannot be just resent. How would closing
keepalives earlier improve the situation?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org