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?
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?
-aaron
>
> Revision Changes Path
> 1.26 +10 -1 httpd-2.0/server/mpm/worker/worker.c
>
> Index: worker.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/server/mpm/worker/worker.c,v
> retrieving revision 1.25
> retrieving revision 1.26
> diff -u -r1.25 -r1.26
> --- worker.c 2001/09/19 06:34:11 1.25
> +++ worker.c 2001/09/19 18:47:31 1.26
> @@ -659,7 +659,16 @@
> signal_workers();
> }
> if (csd != NULL) {
> - ap_queue_push(worker_queue, csd, ptrans);
> + rv = ap_queue_push(worker_queue, csd, ptrans);
> + if (rv) {
> + /* trash the connection; we couldn't queue the connected
> + * socket to a worker
> + */
> + apr_socket_close(csd);
> + ap_log_error(APLOG_MARK, APLOG_CRIT, 0, ap_server_conf,
> + "ap_queue_push failed with error code %d",
> + rv);
> + }
> }
> }
> else {
>
>
>
