httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: keepalive connections and exiting MPM processes
Date Tue, 13 Nov 2007 15:38:45 GMT
On Nov 13, 2007 8:57 AM, Plüm, Rüdiger, VF-Group
<ruediger.pluem@vodafone.com> wrote:
>
>
> > -----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.

...

> > 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).

Apart from the SHOULD vs. MUST is the end-user issue when the client
software can't or won't retry automatically when confronted with a
validly-dropped connection ;)

Mime
View raw message