> > > 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.
> >
> > Ryan
> >
>
> I agree with you Ryan. Haven't thought about this much over the weekend, but my
>inclination is that
> a combination of strategies is required. First, split the scoreboard into two, one
>for process
> management and one for status. The process management scoreboard will be small
>enough to enable us
> to overcommit processes to compensate for multiple processes being restarted at
>once. Then as Greg
> suggests, put some bounds on the number of process that may be in restart.
I am 100% on board with splitting the scoreboard. I disagree with putting
bounds on the number of processes allowed in restart however. I don't see
how it is possible to get around the problem outlined above. I haven't
really thought it through though, so I could easily be missing something.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
