httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: logging APR errors
Date Fri, 14 Jul 2000 22:42:56 GMT

This is not a dirt simple solution, it just looks like one.  Let me give a
few examples.

ap_sendfile.  It fails for some reason.  So, APR generates a char *
"ap_sendfile failed because NODELAY was set"  This is all information
inside of APR.  APR calls this Apache registered function, which takes a
char *.

Apache has to do something with the char * it was passed.  Presumably it
would like to write this out to the error log, but it can't, because it
doesn't have a request_rec or server_rec.  So, it has to save it
aside.  But there, there's no place to save it.  We can't save it to a
static char *, because we are a threaded program.  We can save it to the
thread pool, but that means adding a char * to the thread pool, and if we
are going to do that, we may as well ignore the function and just have APR
fill out the char * by itself.

Yes, this solution could work, if Apache didn't care about the context of
it's logs.  Apache does, as do most programs.  I don't see the solution to
what to do with the string.  We can't log it, because we just don't have
enough information in the Apache log function.


On Fri, 14 Jul 2000, Bill Stoddard wrote:

> > What does that function look like?  Is it going to look just
> > like Apache's error log functions?
> The interface should support the types of extended error information APR might need to
report. It
> shouldn't be tied to any application. The interface could be as simple as a char * or
more complex,
> depending solely on APRs needs.  The 'extended error reporting' function Apache registers
with APR
> would 'do the right thing' with the data passed in, i.e., write it to the error log in
the common
> case. The extended error reporting function would NOT attempt to alter Apache's operation,
that is
> up to whatever Apache function that called APR based on ap_status_t returned by the APR
> This is a dirt simple solution that would solve 99% of the cases of interest to Apache.
> Bill

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message