httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: cvs commit: httpd-2.0/support ab.c
Date Wed, 24 Apr 2002 17:23:26 GMT
comments below...

On Wed, Apr 24, 2002 at 05:09:59PM -0000, aaron@apache.org 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

Mime
View raw message