On 11/13/07 8:30 AM, "Jeff Trawick" <[EMAIL PROTECTED]> wrote:
> * 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 reasonable.
We do so many checks in this function, and it's a pain to modify. I wish
this were a hook. I have selfish reasons for this, as I want an easy way to
limit the number of keepalives per child (especially in event mpm). It
would be so much easier if this were a hook:
In event somewhere:
static can_http_keepalive(request_rec *r) {
if (current_num_of_keepalives + 1 > configured_max) {
return NO; /*whatever, not OK or declined...*/
}
return OK;
}
When resources get tight, I'd like to disable keepalives so I don't have all
the "freeloading" connections hanging around. (Sometimes every little bit
helps...)
Also, shouldn't Keepalive become HTTPKeepalive and live in the http_module's
config (which doesn't exist, I don't think) rather than is "global"
server_rec. Keepalive doesn't make sense for mod_ftp, mod_dns, etc.
While I'm thinking about this, shouldn't virtual server selection be a hook
rather than the current "core" way... Would make eventually "dynamic"
server_rec creation easier.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
