httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Marr <>
Subject Re: logging APR errors
Date Mon, 17 Jul 2000 20:26:11 GMT
At 12:31 PM 07/17/2000 -0700, you wrote:
>On Mon, 17 Jul 2000, Greg Marr wrote:
> > Isn't there one pool per (server_req/request_req), and one (server_req /
> > request_req) per pool?  If so, then there's no problem, because the
> > user_data is unique per pool, and that's where the callback is registered.
>There is one pool per request_rec, but we aren't always in the middle of a 
>request when we want to log things.

So?  If there isn't a request_req now when Apache is logging something, 
then it mustn't require a request_req to log it, now would it?

> > "in APR functions which invoke multiple syscalls, and ... where our
> > experience shows that it would be useful."  I don't see anything here that
> > says anything about Apache, unless you consider "our" to refer to Apache
> > developers instead of APR developers.  If the APR function can fail in 
> more
> > ways than can be described with a simple integer error code, or there is
> > additional error information that could be provided, then the callback is
> > used.  If the function's failure can be defined by a small range of
> > integers, then that's what is returned, and no extra error-reporting is 
> needed.
>Take a closer look at which information is to be logged.  There is no 
>reason that the information should be restricted to the functions that use 
>multiple system calls.  Those functions have already been chosen because 
>the Apache developers are having problems.  The simple fact that we are 
>talking about only doing the extra logging for some functions proves that 
>this is being tied to Apache.

Those functions have been chosen because a client of APR are having 
problems.  The fact that they are Apache developers is irrelevant.  If Jeff 
wasn't an Apache developer but was working on another project at the time, 
would you still say that the functions have been chosen because Apache 
developers are having problems?  The only thing that it proves is that the 
APR function can't return enough information in a restricted int to 
completely specify the error.

> > Why can't the callback know which conditions it wants to log and which it
> > doesn't?  If Apache knows when to log the error and when not to, then
> > Apache knows when to log the error and when not to.
>Because the callback doesn't have that kind of state information.  Unless 
>Apache sends a flag to APR that says "This is where we are in the 
>processing", the callback will never have the right information.  The 
>callback just can't have enough information to know what to log and what 
>not to log.  If it does have that much information, then that is one more 
>thing that Apache is passing down, or it is going to be a very large

Can you give a reasonable example of this?

> > Regardless of whether or not we only make the callback in some places, we
> > don't add extra function calls to the non-error cases.  No non-error cases
> > call the function, since it's an error-reporting function.
>There are multiple calls to ap_stat.  We log failures for some of these, 
>and not for others.  Unless Apache de-registers the callback function, or 
>pushes a NULL function pointer, we will log ALL failures for ap_stat.

Only if the APR developers decide that the success or failure of ap_stat 
can not be described adequately using the existing ap_status_t.  I don't 
see how that can possibly be the case.

>   This need to modify the error handling stack MUST be done for all APR 
> calls, for reasons outlined in earlier messages.  This means that we must 
> add a function call in the main-line code.  Unless the "don't log" flag 
> is passed to the error logging callback.  Which just adds to the 
> hackiness of this solution.

So you're saying that ap_stat can fail in so many different ways that all 
of the information about the failure can not be returned in an int?  I 
don't believe that.

View raw message