comments below...
On Wed, Apr 24, 2002 at 05:09:59PM -0000, [EMAIL PROTECTED] wrote:
> aaron 02/04/24 10:09:59
>
> Modified: support ab.c
> Log:
> Major improvement in concurrent processing for AB:
> - Enable non-blocking connects.
> - Prevent quasi-blocking mode apr_recv (which would prevent AB from
> multiplexing over the entire descriptor set).
> - Catch other fatal apr_recv() errors.
>
> [This patch is slightly different than the one posted to the dev list,
> but regardless thanks to the many people who reviewed this.]
...
> @@ -941,16 +945,21 @@
> char respcode[4]; /* 3 digits and null */
>
> r = sizeof(buffer);
> - apr_setsocketopt(c->aprsock, APR_SO_TIMEOUT, aprtimeout);
> status = apr_recv(c->aprsock, buffer, &r);
> - if (r == 0 || (status != APR_SUCCESS && !APR_STATUS_IS_EAGAIN(status))) {
> + if (APR_STATUS_IS_EAGAIN(status))
> + return;
> + else if (r == 0 && APR_STATUS_IS_EOF(status)) {
This is the part that changed from yesterday's patch. Now we distinguish
between EOF and EAGAIN, and if there is another non-SUCCESS status then
we treat that as fatal. In my tests I ran against the worker MPM and hit
restart and graceful a few times, which didn't trigger an error here. As
soon as I hit stop AB would error out with:
apr_recv: Connection reset by peer (104)
This seems to be the correct behavior to me. Please test this
and make sure it works on all our quirky systems.
> good++;
> close_connection(c);
> return;
> }
> -
> - if (APR_STATUS_IS_EAGAIN(status))
> - return;
> + /* catch legitimate fatal apr_recv errors */
> + else if (status != APR_SUCCESS) {
> + err_except++; /* XXX: is this the right error counter? */
> + /* XXX: Should errors here be fatal, or should we allow a
> + * certain number of them before completely failing? -aaron */
> + apr_err("apr_recv", status);
> + }
>
> totalread += r;
> if (c->read == 0) {
This is a question for the previous ab developers. How lenient should
we be with a single apr_recv error? I tend to think it should be fatal,
but could be persuaded otherwise.
-aaron
