httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: logging APR errors
Date Mon, 17 Jul 2000 22:09:03 GMT
On Mon, 17 Jul 2000, Greg Marr wrote:
> At 01:59 PM 07/17/2000 -0700, rbb@covalent.net wrote:
> >On Mon, 17 Jul 2000, Greg Marr wrote:
> > > At 12:54 PM 07/17/2000 -0700, rbb@covalent.net wrote:
> > > >Take a closer look.  I didn't even have to really search the code.  At
> > > >times, Apache logs errors for ap_stat, at other times it doesn't.  I would
> > > >bet there are more functions like that.
> > >
> > > The ap_stat function is a bad example.  It doesn't need extended error
> > > handling.
> >
> >It is an example of logging not always being needed.  Yes, I could search 
> >the code and find an example of an APR function that requires extended 
> >logging sometime being logged, and sometimes not.  I don't have the time 
> >nor inclination to do so.
> 
> How can you use it as a reason why the scheme doesn't work when you can't 
> back up your reason.
>

Not having time nor inclination is not the same as can't.  But fine.  Here
is an actual example of this.  In fact, the problem is ap_Sendfile.

On Windows, ap_sendfile can fail because sendfile isn't on 95/98.  If
sendfile fails on those machines, we don't want to log the error, we just
want to use another mechanism for sending the file.  On NT, sendfile can
fail for other reasons.  The same code must be executed in both cases.  In
fact, the proposed solution doesn't solve this problem at all, because now
the error logging handler must deal with a certain error from sendfile
differently than the same error from some other function.

Take a look at rfc1413.c.  Look for ap_canoncial_error.  In this case,
depending on the error returned, we do or do not log the error.

No look at http_log.c.  We have ap_open_stderr.  We have at least three
calls to this, although we log it in an unusual way, we are logging two of
them, and not the third.

Now look at mpmt_pthread at SAFE_ACCEPT.  This does an ap_lock under the
covers.  We log that.  We don't log ap_lock in mod_auth_digest.c

> That's my point exactly, thank you.  Sometimes when an APR call fails, the 
> error needs to be logged by the app that called the function, and sometimes 
> it doesn't.  That doesn't seem like an awful hack to me.

Then one of us is seriously not understanding the design.  The current
design doesn't allow for this as I understand it.  All complex
APR functions call this error-logging handler, and it does the
logging.  The App doesn't get to control which calls get logged and which
don't.  In order to control that, we need to add or remove a logging
handler before the call to the APR function.  The code has to look like:

ap_push_logging_function(pool, log_error);
ap_sendfile(...);
ap_pop_logging function(pool);

This is affecting the case where there is no error.  That is what I don't
want to see.  I see no way using this design to get around that penalty.

> Because the logging function doesn't know where we are in the
> code.  It isn't the type of  error, it's where in the processing of a
> request the error occured.  It is based on the state of Apache, not the
> error itself.
> 
> You haven't shown an example where this is the case.
> 

Because I am just not going to spend the rest of my day searching the
code, the best example I can give right now is
ap_get_win32_interpreter.  Again, one function, two calls, one to
ap_log_error and one to ap_log_rerror.  Right now, this code isn't
APR-ized.  It should be.  We have the request_rec, but we don't always
want to use it.

> >Yes, which function to call can be passed down, but that requires 
> >inserting that information before each call to APR function.  This is 
> >overhead in the main-line case.  Get rid of that overhead in the main-line 
> >(no error) case, and I will no longer consider this a hack.
> 
> The overhead hasn't been shown to exist yet.  If you can show that there is 
> a case where this overhead can exist, and no one can show a method that 
> eliminates this overhead, then I might agree with you.

Yes it has.  See above.  Because we can't just use the userdata to
determine which logging function should be called in
ap_get_win32_interpreter, we have to pop and push the logging
handler.  There's the overhead.

> I just had another thought.  Someone recently mentioned something about 
> returning a list of errors from a function.  Is there ever a possibility of 
> multiple "errors" in the same function?  That is, can an APR function run 
> into an error from a system function, but still be able to continues on 
> with the execution of the function, perhaps through another system 
> call?  If so, how would the integer error code deal with something like 
> that?  Is that something that the application would care about?  It would 
> be very straight-forward for the callback scheme to log that non-fatal error.

When an APR function fails, it returns imeediately.  If the APR function
can get around the failure, then it isn't a failure, it is
sub-optimal.  Those are different cases.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------



Mime
View raw message