I/O timeouts in A2 (was Re: Pools and Threads and Errors)

[Ben Hyde <bh...@pobox.com>]

Dean Gaudet writes:
>> >If you look at how we currently use timeouts, we use them to get back from
>> >network/pipe reads and writes.  That's pretty easy to implement via select
>> >under unix (and I know it can be done under NT, I just don't know the
>> >mechanism -- NSPR implements it).  The NSPR port adds a timeout parameter
>> >to BUFF, and all reads or writes on that BUFF respect the timeout.
>> 
>> Yes all I/O operations should time out.  Presumably when BUFF get that
>> a timeout it marks the BUFF as dead in some sense?
>
>It calls the previously unused error handler for the BUFF, which gives the
>user a chance to do something special.  I forget exactly what I did. 

Unused in the core code possibly.

Could not timing out the I/O be handled much as losing the connection,
except for possibly the log message?

 - ben

Re: I/O timeouts in A2 (was Re: Pools and Threads and Errors)

[Ben Hyde <bh...@pobox.com>]

I yearn for a general "error occurred callback" scheme along these
lines.  Consider for example the use of how ap_log_error is used in
src/os/unix - it ought to stand on something low level rather than
something in main/.  I lean toward moving alloc.c, some of http_log.c,
and the stack/thread management abstractions into something place
lower level than main/.  They are more like language extensions.

If we not going to allow the destruction of threads than a cleaner
exception/logging/unwinding scheme would be nice.

 - ben

Dean Gaudet writes:
>On Thu, 14 Jan 1999, Ben Hyde wrote:
>> Dean Gaudet writes:
>> >It calls the previously unused error handler for the BUFF, which gives the
>> >user a chance to do something special.  I forget exactly what I did. 
>> 
>> Unused in the core code possibly.
>
>Yeah it doesn't really affect others I don't think.  I think I just
>cleared up the semantics.  Maybe.
>
>> Could not timing out the I/O be handled much as losing the connection,
>> except for possibly the log message?
>
>/* XXX: this should really take a request_rec as the data, so that info
> * about the pathname causing the error can be displayed.  But to do that
> * the child_main loop needs to be careful about calling ap_bonerror()
> * after it destroys the request.  Deal with that later.
> */
>static void client_bonerror_handler(BUFF *fb, int direction, void *vb)
>{
>    conn_rec *conn;
>    const char *errstr;
>
>    switch (PR_GetError()) {
>    case PR_IO_TIMEOUT_ERROR:
>        errstr = "client %s timed out during %s (%s)";
>        break;
>
>    case PR_CONNECT_RESET_ERROR:
>        errstr = "client %s stopped connection before %s (%s) completed";
>        break;
>
>    default:
>        errstr = "client %s had an i/o error during %s (%s)";
>        break;
>    }
>    conn = vb;
>    ap_log_error(APLOG_MARK, APLOG_INFO, conn->server, errstr,
>                conn->remote_ip,
>                conn->timeout_name ? conn->timeout_name : "request",
>                (direction == B_RD) ? "read" : "write");
>}
>
>... and in ap_read_request we have:
>
>    ap_bonerror(conn->client, client_bonerror_handler, conn);
>    conn->timeout_name = "read request line";
>    ap_bsetopt(conn->client, BO_TIMEOUT,
>        conn->keptalive
>            ? &r->server->keep_alive_timeout_interval
>            : &r->server->timeout_interval);
>
>folks can play with conn->timeout_name to change what's logged.
>
>Dean
>
>

Re: I/O timeouts in A2 (was Re: Pools and Threads and Errors)

[Dean Gaudet <dg...@arctic.org>]

On Thu, 14 Jan 1999, Ben Hyde wrote:

> Dean Gaudet writes:
> >It calls the previously unused error handler for the BUFF, which gives the
> >user a chance to do something special.  I forget exactly what I did. 
> 
> Unused in the core code possibly.

Yeah it doesn't really affect others I don't think.  I think I just
cleared up the semantics.  Maybe.

> Could not timing out the I/O be handled much as losing the connection,
> except for possibly the log message?

/* XXX: this should really take a request_rec as the data, so that info
 * about the pathname causing the error can be displayed.  But to do that
 * the child_main loop needs to be careful about calling ap_bonerror()
 * after it destroys the request.  Deal with that later.
 */
static void client_bonerror_handler(BUFF *fb, int direction, void *vb)
{
    conn_rec *conn;
    const char *errstr;

    switch (PR_GetError()) {
    case PR_IO_TIMEOUT_ERROR:
        errstr = "client %s timed out during %s (%s)";
        break;

    case PR_CONNECT_RESET_ERROR:
        errstr = "client %s stopped connection before %s (%s) completed";
        break;

    default:
        errstr = "client %s had an i/o error during %s (%s)";
        break;
    }
    conn = vb;
    ap_log_error(APLOG_MARK, APLOG_INFO, conn->server, errstr,
                conn->remote_ip,
                conn->timeout_name ? conn->timeout_name : "request",
                (direction == B_RD) ? "read" : "write");
}

... and in ap_read_request we have:

    ap_bonerror(conn->client, client_bonerror_handler, conn);
    conn->timeout_name = "read request line";
    ap_bsetopt(conn->client, BO_TIMEOUT,
        conn->keptalive
            ? &r->server->keep_alive_timeout_interval
            : &r->server->timeout_interval);

folks can play with conn->timeout_name to change what's logged.

Dean