On Wednesday 19 September 2001 12:11 pm, Aaron Bannert wrote:
> On Wed, Sep 19, 2001 at 06:47:31PM -0000, [EMAIL PROTECTED] wrote:
> > trawick 01/09/19 11:47:31
> >
> > Modified: server/mpm/worker worker.c
> > Log:
> > if we're gonna trash the connection due to a queue overflow, at the
> > very least we should close the socket and write a log message (mostly
> > to aid debugging, as this is a showstopper problem)
> >
> > this is no fix; there is a design issue to consider; hopefully this
> > will
>
> [I assume you had more to say?]
>
> Yes, you are absolutely correct. I am so glad you caught that. This
> reveals another design issue:
>
> Now that the queue represents the number of accepted-but-not-processed
> sockets, it does not necessarily need to be the size of the number of
> threads, but instead some other value that indicates the number of
> sockets we'll accept before sending back some "Server Busy" error.
>
> So I have two questions:
>
> 1) How do we send back that error?
You can't. There is no way to determine how busy the other processes are.
> 2) How long should the queue be? Should we just set some arbitrary
> constant, defined in mpm_default.h, or should we come up with some
> heuristic?
Manoj actually ran tests about this back when we were using the apache-apr
repository. In his tests, the optimal length was equal to the number of threads.
Having a bit of wiggle room just didn't get us anywhere.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
