[EMAIL PROTECTED] wrote:
>
> On Sun, 22 Apr 2001, Greg Ames wrote:
>
> > Bill Stoddard wrote:
> > >
> > > >
> > > > AFAIK, Paul hit this problem because of idle_server_maintenance and/or
> > > > MaxRequestsPerChild - true? If that's really the extent of it, I
> > > > believe there's a pretty easy solution.
> >
> > > >
> > > > If you buy that, then why doesn't that solution work for
> > > > MaxRequestsPerChild as well?
> >
> > >
> > > True (IMHO).
> > >
> > > > For the low end folks it's probably the default anyway, which we
> > > > developers just pulled out of the air. So if we have our mixed workload
> > > > process basket case scenario going on, just hold off on killing any more
> > > > processes until the first one terminates completely.
> > >
> > > Show us some code :-)
> > >
> >
> > OK, it's committed...works swell for me. Paul?
>
> Um... This is an incredibly dangerous change. This makes Apache shutdown
> one threaded process at a time. I think we have all downloaded tarballs
> that are hundreds of megs, which can take a few hours to download. What
> happens if while my server is serving one of those files, I need to do a
> graceful restart to re-config my server. If the first process shutdown is
> the one with the thread serving a three hour request, then my server won't
> actually restart for 3 hours.
>
It doesn't affect any operator initiated shutdown/restart commands, only
internal algorithmically generated things like
perform_idle_server_maintenance and MaxRequestsPerChild.
That said, there's something wrong with it. Processes with no worker
threads were hanging
around forever, like before the fix to do the joins. So I just disabled
it.
Greg
