httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ics.uci.edu>
Subject Re: [PATCH] night of the dead apache
Date Wed, 05 Nov 1997 06:20:22 GMT
>Roy, this seems to fix the bug for me.  I did a bunch of trussing against
>the children and tried a bunch of signals and this seems to deal with all
>of them except SIGKILL, as expected. 

Nope, not here.  The mutex isn't working at all.  Several times more
than one child got the lock and are waiting on accept, usually resulting
in one of them getting an ECONNRESET.  I was also able to get it into
a state where no child had the mutex, once again resulting in a complete
server hang until I -HUPd the parent.

My test setup is simple.  I have an X-window for each child and the parent,
all running truss -p pid.  With the default config + mod_status + mod_info

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 2
MaxSpareServers 4
StartServers 4
MaxClients 150
MaxRequestsPerChild 60

I can generate a stream of requests using a single Netscape client
such that the four original children are all handling requests and
all hit the keep-alive timeout at the same time (meaning that one
of the new children started during the mass of requests has the mutex).
I then wait for the timeouts to expire and make server-status requests
watching each child pick up the lock as the last lockholder receives a
request.  On a working mutex, only one child should be waiting for
the next connection (accept/getmsg) and the rest should be blocked on
lwp_mutex_lock (or whatever syscall is used for the locking).

With the patch and PTHREAD enabled, two children are usually waiting
for the next connection and two are on lwp_mutex_lock, sometimes one,
and eventually none (with no apparent pattern).  In other words,
there is a race condition somewhere.

If anyone wants a good test sample for a hundred different inline images
on a single page, mine is available from

    http://websoft.ics.uci.edu/icon_test.tar.gz

Note that it only tests basic file requests (and large indexes if you
just request the directory).  I suppose it would be easy to turn it
into a multiviews stresser as well.

....Roy

Mime
View raw message