Based on my experience, this wouldn't be a high-quality solution, it would
be a hack. I've seen very few cases where load spiked enough to be an
issue, but was transient enough that a solution like this would work - and
in those cases, plain old Unix multitasking normally suffices.
What happens i
On Thu, 17 Oct 2002, William A. Rowe, Jr. wrote:
> With the simultaneous release of Apache 2.1-stable and Apache
> 2.2-development, the Apache HTTP Server project is moving to a more
> predictable stable code branch, while opening the development to forward
> progress without concern for breaking t
On Wed, 25 Sep 2002, Sander van Zoest wrote:
> On Wed, 25 Sep 2002, Justin Erenkrantz wrote:
> > On Thu, Sep 26, 2002 at 02:11:59AM +0200, Dirk-Willem van Gulik wrote:
> > > ->Makes the wait loop no longer endless - but causes it
> > > to bail out (and emit some warnings ahead of time) a
On Thu, 12 Sep 2002, Harrie Hazewinkel wrote:
> --On Thursday, September 12, 2002 8:50 AM -0500 "Jenkins, David"
> > I disagree almost completely. If you are truly dedicated to the ASF
> > community, you will understand the cautiousness necessary in deciding
> > who has commit privs.
>
> I was
[I am not an Apache contributor, merely a lurker, but...]
On Tue, 10 Sep 2002, Jon Travis wrote:
> These are not coercive tactics. These are processes which are
> beneficial to both the ASF and Covalent. I cannot continually monitor
> the progress of this project for eternity. I'm astonished t
I'm not sure I understand what your goal is, here. The discussion seems
to be +1 for including your parser somewhere in some Apache project in the
future, there's just no clear concensus on where. Is there any reason you
can't just release your project under the ASF license and be done with it?
On Thu, 15 Aug 2002, William A. Rowe, Jr. wrote:
> There's no reason to bloat all of Apache and it's well behaved modules
> with extra code, when only a handful of modules care to report that they
> can't be compiled for a threaded architecture.
The strict engineer in me agrees. The pragmatic en
On Mon, 20 May 2002, Greg Stein wrote:
> On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
> > On Win32, we load-unload-reload the parent, then load-unload-reload
> > the child config. Losing both redundant unload-load sequences will
> > be a huge win at startup.
>
> Yup. I
On Thu, 16 May 2002, Joshua Slive wrote:
> On Thu, 16 May 2002, Ryan Bloom wrote:
> > My own opinion is that we leave things exactly as they are today. If
> > you are running the binary by hand, you are taking some responsibility
> > for knowing what you are doing. That means having the environm
In my experience this argument always ends with: copy the ,v files, then
cvs rm the old version, with a comment on the order of "moved to
../wherever". Perhaps with a "moved from .../wherever" comment added to
the new version. I think it's even ended that way on this list a couple
times.
Messi
On Wed, 20 Mar 2002, Stas Bekman wrote:
> mod_perl child processes save a lot of memory when they can share memory
> with the parent process and quite often we get reports from people that
> they lose that shared memory when the system decides to page out the
> parent's memory pages because they a
On Thu, 21 Mar 2002, Stas Bekman wrote:
> > On Wed, 20 Mar 2002, Stas Bekman wrote:
> >
> >>mod_perl child processes save a lot of memory when they can share
> >>memory with the parent process and quite often we get reports from
> >>people that they lose that shared memory when the system decid
the children killing themselves when the parent goes
away, perhaps configurable between "Kill yourself ASAP" versus "Kill
yourself when you come up for air between requests." The notion of
killing everything which _looks_ like an Apache child scares me (what if
you're running multiple servers on a box?).]
Later,
scott hess
[EMAIL PROTECTED]
13 matches
Mail list logo