httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VF-Group <ruediger.pl...@vodafone.com>
Subject Re: keepalive connections and exiting MPM processes
Date Tue, 13 Nov 2007 13:57:07 GMT


> -----Ursprüngliche Nachricht-----
> Von: Jeff Trawick 
> Gesendet: Dienstag, 13. November 2007 14:31
> An: dev@httpd.apache.org
> Betreff: keepalive connections and exiting MPM processes
> 
> 
> When the MPM process handling the connection is or will be exiting, we
> can incorrectly tell the client that the connection will be held open
> after the current request.  This can result in user intervention
> (retry the POST?) or failures for some requests sent subsequently on
> that connection.
> 
> The case where we already know we're exiting at the time we determine
> the keep-alive setting is simple to handle:
> 
> Index: modules/http/http_protocol.c
> ===================================================================
> --- modules/http/http_protocol.c        (revision 593813)
> +++ modules/http/http_protocol.c        (working copy)
> @@ -48,6 +48,7 @@
>  #include "util_charset.h"
>  #include "util_ebcdic.h"
>  #include "util_time.h"
> +#include "ap_mpm.h"
> 
>  #include "mod_core.h"
> 
> @@ -187,6 +188,7 @@
>       *       or they're a buggy twit coming through a HTTP/1.1 proxy
>       *   and    the client is requesting an HTTP/1.0-style keep-alive
>       *       or the client claims to be HTTP/1.1 compliant 
> (perhaps a proxy);
> +     *   and this MPM process is not already exiting
>       *   THEN we can be persistent, which requires more 
> headers be output.
>       *
>       * Note that the condition evaluation order is extremely 
> important.
> @@ -212,7 +214,8 @@
>          && (!apr_table_get(r->subprocess_env, "nokeepalive")
>              || apr_table_get(r->headers_in, "Via"))
>          && ((ka_sent = ap_find_token(r->pool, conn, "keep-alive"))
> -            || (r->proto_num >= HTTP_VERSION(1,1)))) {
> +            || (r->proto_num >= HTTP_VERSION(1,1)))
> +        && !ap_graceful_stop_signalled()) {
>          int left = r->server->keep_alive_max - 
> r->connection->keepalives;
> 
>          r->connection->keepalive = AP_CONN_KEEPALIVE;

Looks like a reasonable patch.

> 
> It isn't so clear how to handle the remaining window, in which the MPM
> process starts exiting while we send the response (and after we've
> already determined the keepalive setting).
> 
> From ap_process_http_connection():
> 
>         if (r->status == HTTP_OK) {
>             cs->state = CONN_STATE_HANDLER;
>             ap_process_request(r);
>             r = NULL;
>         }
> 
>         if (c->keepalive != AP_CONN_KEEPALIVE || c->aborted)
>             break;
> 
>         XXXXXXXXXXX
>         We could skip checking for graceful exit here since 
> it is checked
>         as part of the keepalive determination, but the MPM process
>         could remain active much longer than expected (maybe we just
>         downloaded a very large file).
>         XXXXXXXXXXX
> 
>         if (ap_graceful_stop_signalled())
>             break;
> 
> For the remaining timing window, I'm afraid that a vhost-specific
> setting is needed to control whether we respect the connection
> keepalive setting or the MPM state.   (The latter is apparently good

I guess we can leave it as it is in this situation. Although we SHOULD
send connection: close if want to close the connection it is no MUST
(8.1.2.1, last sentence first paragraph). And for pipelined requests the
client must be prepared to resend anyway if we do not process all pipelined
requests (8.1.2.2).

Regards

Rüdiger



Mime
View raw message