httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@ibm.net>
Subject Re: logging APR errors
Date Wed, 19 Jul 2000 19:24:08 GMT
(trying again after tweaking my mail cfg)

rbb@covalent.net writes:

> > > This design doesn't solve this problem, in fact, IMNSHO it makes it
> > > worse.  Think of it this way.  What if Apache doesn't want to log on a
> > > given error.  Say for ap_sendfile, there is at least one condition we
> > > don't want to log, but it requires the ability to make the call-back
> > > (otherwise we are Apache centric).  Apache must de-register the callback
> > > before calling ap_sendfile.  And then re-register it after calling
> > > ap_sendfile, or Apache will need to register/de-register before EVERY APR
> > > call.  There is only one way aroung this, which is to only make the
> > > callback in the cases Apache cares about, which ties APR to Apache, which
> > > is a BIG no-no.
> > 
> > I seriously doubt that Apache or any other app is going to want to do
> > such a thing, but obviously it is a possibility.
> 
> 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.

ap_stat() isn't such a great example (nothing interesting to log), but
the point is well taken.  A big problem with playing with the user
data directly or the call-back registration in order to avoid a possible 
trace is that it breaks thread-safety.

> So, what you are advocating, is magically logging the error in some cases,
> and making the application log the error in other cases.  This is
> ugly.  This will look like:
> 
> ap_stat(...)
> ap_log_error(.... "Stat failed");
> 
> ap_sendfile(...)
> return;
> 
> This doesn't seem like an awful hack to you?  You are logging some errors
> in your app, and some errors are just magically logged to the log
> file.

It might seem like an awful hack if that were what I am advocating.
For the most part, I like things how they are.  The app calls APR; if
it fails, the app logs it.  The call-back stuff is intended only to
handle the relatively rare cases (perhaps 10% of the APR functions?)
where there is useful information that the caller can't derive from
the return code.  "Which syscall failed?" is such information when the
APR function calls a series of them.  The app would still log the
error returned by APR; a little more info would be passed to the
call-back prior to the return to the app.

> > I can see why putting a string in the pool is a problem.  I don't see
> > why the error call-back is a problem.  This blindness may be due to
> > assuming that the error call-back's user data will stay the same for
> > the life of a pool.  Can you please explain the thread-safe issue?
> 
> How we log is based on where we are in the code, and what information we
> have access to.  Look at scan_script_header_err_core in util_script.  In
> the same file, we are logging using ap_log_error and ap_log_rerror.  This
> example isn't perfect, because we aren't logging based on function return
> values, but it will demonstrate the problem, and I found it in under a
> minute, so if I had more time, I believe I could find an exact example of
> the problem.
> 
> If we pass the same pool with the same user_data to two different APR
> functions, we will always log using the same error function
> (ap_log_error/ap_log_rerror).  Sometimes, even if we have a request_rec,
> we don't want to use ap_log_rerror.  This means that in order to convey
> that to the logging callback, we would have to modify the user_data in
> some way.  Either with a flag, or by removing the request_rec.  Bang, you
> hit thread-safety issues as soon as you have to modify the
> user-data.

gotcha

> > > The design I am leaning most towards right now, is for APR to define a
> > > bunch more error values, and just return them in the correct spots.
> > 
> > I'll look forward to seeing it.
> 
> The code is there, and the design is done.  Add a couple of more error
> values, and return them where appropriate.  This lets the App deal with
> errors, which is the correct solution.

How does "Add a couple of more error values, and return them where
appropriate" solve these problems?

. we don't know which syscall(s) failed
. we need to give the app the opportunity to trace certain
  system-specific information (e.g., name of secondary DLL on OS/2,
  reason code on OS/390); when the extra info can be determined after
  any syscall failure (e.g., OS/390 reason code), the app could
  potentially do the work if it is called before subsequent syscalls
  are made; when the extra info is specific to a certain call (e.g.,
  name of secondary DLL), APR would have to get the info

I don't doubt that you have everything worth solving solved, but it
would be helpful to know what sort of error values you are adding and
whether or not you will be combining it (bitwise) with the existing
error values. 

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

--HAB20763.964092255/k5.localdomain--


Mime
View raw message