httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Unclean process shutdown in event MPM?
Date Tue, 23 Mar 2010 14:04:02 GMT
On 23.03.2010 13:34, Jeff Trawick wrote:
> On Tue, Mar 23, 2010 at 7:19 AM, Rainer Jung<>  wrote:
>> I can currently reproduce the following problem with 2.2.15 event MPM under
>> high load:
>> When an httpd child process gets closed due to the max spare threads rule
>> and it holds established client connections for which it has fully received
>> a keep alive request, but not yet send any part of the response, it will
>> simply close that connection.
>> Is that expected behaviour? It doesn't seem reproducible for the worker MPM.
>> The behaviour has been observed using extreme spare rules in order to make
>> processes shut down often, but it still seems not right.
> Is this the currently-unhandled situation discussed in this thread?
> Perhaps Event's special handling for keepalive connections results in
> the window being encountered more often?

I'd say yes. I know from the packet trace, that the previous response on 
the same connection got "Connection: Keep-Alive". But from the time gap 
of about 0.5 seconds between receving the next request and sending the 
FIN, I guess, that the child was not already in the process of shutting 
down, when the previous "Connection: Keep-Alive" response was send.

So for me the question is: if the web server already acknowledged the 
next request (in our case it's a GET request, and a TCP ACK), should it 
wait with shutting down the child until the request has been processed 
and the response has been send (and in this case "Connetion: Close" was 

For the connections which do not have another request pending, I see no 
problem in closing them - although there could be a race condition. When 
there's a race (client sends next request while server sends FIN), the 
client doesn't expect the server to handle the request (it can always 
happen when a Keep Alive connection times out). In the situation 
observed it is annoying, that the server already accepted the next 
request and nevertheless closes the connection without handling the request.

I will do some testing around your patch

and the discussion in the mail thread you cited.

Thanks for the pointer!



View raw message