You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@raleigh.ibm.com> on 2000/07/14 19:40:46 UTC
logging APR errors
I got the following while trying to get mod_file_cache working on Linux:
[Tue Jul 04 17:13:59 2000] [error] [client 127.0.0.1] (22)Invalid
argument: mod_file_cache: iol_sendfile failed.
Can you tell what failed without running a debugger?
This doesn't even point me to the failing file. But that part is easy -
you know it's Linux, so iol_sendfile always invokes ap_sendfile. If you
go there, you will see 7 syscalls or APR calls for the current Linux
flavor. So which one failed?
Unfortunately, most of these 7 are network related which means they
could fail in production. There's gotta be a better way. I have some
thoughts but would like to hear other opinions first.
Thanks,
Greg
Re: logging APR errors
Posted by Tony Finch <do...@dotat.at>.
"Bill Stoddard" <re...@attglobal.net> wrote:
>
>There are other techniques available as well. Look back a couple of months in this list for Jeff
>Trawick's posts on this exact topic. One method mentioned at the time is to register an application
>specifc (Apache in this case, or perhaps an individual MPM) error handling function with APR at init
>time. This function is called to log the specific failure (function call, failing system call, line
>of code, message string, etc.).
Apart from the problems of threading the application context down into the
error handling function properly, this totally fails to allow the calling
function to decide on a case-by-case basis how to handle an error.
If APR needs to distinguish between errors that would otherwise have the
same status code then it should return different status codes. Just
returning errno in this situation is a bug. (This solution to the problem
is a weaker form of the rich status type that Ken likes.)
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
481 therapeutic body-temp sump dunk
Re: logging APR errors
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Jul 15, 2000 at 12:08:53AM -0400, Rodent of Unusual Size wrote:
>...
> I wish the rich error type hadn't been dissed; this 'one error,
> one int' approach is soooo lame and stupid. Yes, it's the
> Unix way -- but so is decades of non-reentrant libc routines.
> The rich error type has about a quarter of a century of
> untainted elegant success.. but oh well.
mod_dav uses the following structure:
typedef struct dav_error {
int status; /* suggested HTTP status (0 for no error) */
int error_id; /* DAV-specific error ID */
const char *desc; /* DAV:responsedescription and error log */
int save_errno; /* copy of errno causing the error */
struct dav_error *prev; /* previous error (in stack) */
} dav_error;
Subversion just went through its error design and settled on:
typedef struct svn_error
{
ap_status_t apr_err; /* APR error value, possibly SVN_ custom err */
int src_err; /* native error code (e.g. errno, h_errno...) */
const char *message; /* details from producer of error */
struct svn_error *child; /* ptr to the error we "wrap" */
ap_pool_t *pool; /* place to generate message strings from */
} svn_error_t;
Just tossing them out for consideration/discussion. I'm not sure that I want
to "discuss" this one too much :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: logging APR errors
Posted by Greg Ames <gr...@raleigh.ibm.com>.
OK - even though there is disagreement on the delivery mechanism, everyone seems to agree
that more detailed error information would be goodness. I have some thoughts about what
the additional information should be:
1. filename & line # of the line of code in the lowest level function that detected the
error. A macro could get this for us.
2. name of the failing syscall (if there is one)
3. parms of the failing syscall (again if there is one). Perhaps these should only be
provided in a development environment to cut down on the output in production.
4. ??saved errno/os-specific error code?? We might be ok here today with the handling of
ap_status_t's. I'm mostly paranoid about loosing the original failure info in a threaded
environment, or when there is error recovery/backout logic within APR itself (rare).
#1 and #2 might be slightly redundant. The idea is to uniquely identify the point where
the failure is detected. #1 seems easy for the APR coder, but it is only useful if you
pull up the source. #2 may let the webmaster figure out what's happening without looking
at the source, but I don't know of an easy/clean way to macro-ize it.
Greg Ames
rbb@covalent.net wrote:
>
> On Sat, 15 Jul 2000, Rodent of Unusual Size wrote:
> >
> > That's Apache's problem. APR's problem is getting a meaningful
> > and complete error message back to the calling application.
> > Let's deal with that first.
>
> I agree completely., but the problem is that the design we are
> discussing does do this. The design being discussed gets a portion of an
> error string to a very limited section of the calling application. I have
> tried to explain why this doesn't work, and why the other designs are more
> complete. I'll keep trying. :-)
>
> > I wish the rich error type hadn't been dissed; this 'one error,
> > one int' approach is soooo lame and stupid. Yes, it's the
> > Unix way -- but so is decades of non-reentrant libc routines.
> > The rich error type has about a quarter of a century of
> > untainted elegant success.. but oh well.
>
> ++1. I agree completely.
>
> Ryan
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
Re: logging APR errors
Posted by rb...@covalent.net.
On Sat, 15 Jul 2000, Rodent of Unusual Size wrote:
> rbb@covalent.net wrote:
> >
> > 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.
>
> That's Apache's problem. APR's problem is getting a meaningful
> and complete error message back to the calling application.
> Let's deal with that first.
I agree completely., but the problem is that the design we are
discussing does do this. The design being discussed gets a portion of an
error string to a very limited section of the calling application. I have
tried to explain why this doesn't work, and why the other designs are more
complete. I'll keep trying. :-)
> I wish the rich error type hadn't been dissed; this 'one error,
> one int' approach is soooo lame and stupid. Yes, it's the
> Unix way -- but so is decades of non-reentrant libc routines.
> The rich error type has about a quarter of a century of
> untainted elegant success.. but oh well.
++1. I agree completely.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: logging APR errors
Posted by rb...@covalent.net.
On Sat, 15 Jul 2000, William A. Rowe, Jr. wrote:
> > rbb@covalent.net wrote:
> > >
> > > 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.
> >
> > That's Apache's problem. APR's problem is getting a meaningful
> > and complete error message back to the calling application.
> > Let's deal with that first.
> >
> > I wish the rich error type hadn't been dissed; this 'one error,
> > one int' approach is soooo lame and stupid. Yes, it's the
> > Unix way -- but so is decades of non-reentrant libc routines.
> > The rich error type has about a quarter of a century of
> > untainted elegant success.. but oh well.
>
> Then I ask, for common sense sake, what the vote was. (pro/con.)
>
> I'm thinking there is another avenue. It might cause headaches
> in terms of meeting individual developer's schedules. But for the
> sake of argument, can someone point out the best argument 'against'
> rich error results?
The arguments against rich error text are some where in the
archives. I'll try to remember them, but I couldn't find them yesterday
when I went looking.
The argument against returning an error string, was that we could be
allocating the string unnecessarily. Basicallly, just because an APR
function failed, that doesn't mean we are going to log an error
message. This is actually another place where the log function falls
down. In the design being discussed, there is no way to not log an error,
unless we un-register the error function before we call the APR
function. That means that we have to either register or un-register the
function before every APR call.
The argument against the rich error type, was that it just wasn't
necessary. At least I thnk that was the argument. Basically, Unix and
NSPR didn't need any more than an int per error, so neither does APR.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: logging APR errors
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> Sent: Friday, July 14, 2000 11:09 PM
> To: new-httpd@apache.org
>
> rbb@covalent.net wrote:
> >
> > 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.
>
> That's Apache's problem. APR's problem is getting a meaningful
> and complete error message back to the calling application.
> Let's deal with that first.
>
> I wish the rich error type hadn't been dissed; this 'one error,
> one int' approach is soooo lame and stupid. Yes, it's the
> Unix way -- but so is decades of non-reentrant libc routines.
> The rich error type has about a quarter of a century of
> untainted elegant success.. but oh well.
Then I ask, for common sense sake, what the vote was. (pro/con.)
I'm thinking there is another avenue. It might cause headaches
in terms of meeting individual developer's schedules. But for the
sake of argument, can someone point out the best argument 'against'
rich error results?
Bill
Re: logging APR errors
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> 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.
That's Apache's problem. APR's problem is getting a meaningful
and complete error message back to the calling application.
Let's deal with that first.
I wish the rich error type hadn't been dissed; this 'one error,
one int' approach is soooo lame and stupid. Yes, it's the
Unix way -- but so is decades of non-reentrant libc routines.
The rich error type has about a quarter of a century of
untainted elegant success.. but oh well.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: logging APR errors
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> > existing_log_function_call (normal_parms, apr_registered_error_handler (rc));
> >
> > where the apr_registered_error_handler knows how to make the most sense of the
> > situation (including error text, file, linenumber, etc) to generate a useful error
> > log.
>
> But what do you do with that log string at that point? You have no place
> to store it that can be returned to Apache.
Now I understand. I had assumed that it could be allocated out of the pool
from the request being processed and returned in the request rec or logged
directly (if possible).
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: logging APR errors
Posted by rb...@covalent.net.
On Fri, 14 Jul 2000, Paul J. Reder wrote:
> rbb@covalent.net wrote:
> Again, I apparently misunderstood Jeff's design. As I understood it, the error
> handler did not do the logging. The registered error handler (default or Apache)
> is just responsible for using available information to create the log text. The
> error handler, being system specific, knows how to look in "the right" places
> (whether that be errno, a return code, or a system function to obtain error state).
> APR or Apache or whatever knows when a return code has been generated. I envisioned
> the event being handled as something like
That doesn't buy us anything, because there is no place to store the
string. APR can generate the entire string all by itself. The only thing
it can't do is return that string to Apache.
> existing_log_function_call (normal_parms, apr_registered_error_handler (rc));
>
> where the apr_registered_error_handler knows how to make the most sense of the
> situation (including error text, file, linenumber, etc) to generate a useful error
> log.
But what do you do with that log string at that point? You have no place
to store it that can be returned to Apache.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: logging APR errors
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> 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.
Again, I apparently misunderstood Jeff's design. As I understood it, the error
handler did not do the logging. The registered error handler (default or Apache)
is just responsible for using available information to create the log text. The
error handler, being system specific, knows how to look in "the right" places
(whether that be errno, a return code, or a system function to obtain error state).
APR or Apache or whatever knows when a return code has been generated. I envisioned
the event being handled as something like
existing_log_function_call (normal_parms, apr_registered_error_handler (rc));
where the apr_registered_error_handler knows how to make the most sense of the
situation (including error text, file, linenumber, etc) to generate a useful error
log.
Now maybe the error handler is too much overhead, but I still don't see how it
adds any code other than during error path and even there it is a single function
call (no extra if logic).
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: logging APR errors
Posted by rb...@covalent.net.
On Sat, 15 Jul 2000, Rodent of Unusual Size wrote:
> rbb@covalent.net wrote:
> >
> > I do consider registering an error function with APR to be a hack.
>
> But as has been pointed out, that doesn't necessarily make it
> so. And even if it were, having no way to get meaningful and
> relevant errors back to the app is worse.
But getting those messages back is easy. Even if all we do is save the
error string in the pool that was passed into the APR function. (although
that doesn't strictly work either). What we really need, is the rich
error type that was designed two years ago.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: logging APR errors
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> I do consider registering an error function with APR to be a hack.
But as has been pointed out, that doesn't necessarily make it
so. And even if it were, having no way to get meaningful and
relevant errors back to the app is worse.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: logging APR errors
Posted by rb...@covalent.net.
On Fri, 14 Jul 2000, Bill Stoddard wrote:
> >
> > 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.
>
> Okay, this has to my last response to this thread (at least for the week)...
>
> Create ap_get_server_conf() to call the MPM to fetch a static pointer to server_conf. Now you have
> what you need to call ap_log_error(). I've done this and it works fine. Maybe overlooking some other
> details.
This doesn't really solve the problem though. What if you want to log
with log_rerror, because that makes more sense based on which function has
failed. This is where the hack has come into play. With this design, we
first make a call out of APR into Apache, and then make a call from the
protocol module to the MPM.
This is compared to making no calls. Just allocating a string out of the
pool, and saving the error to the string. Apache can then just grab that
string.
I do consider registering an error function with APR to be a hack.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: logging APR errors
Posted by Bill Stoddard <re...@attglobal.net>.
>
> 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.
Okay, this has to my last response to this thread (at least for the week)...
Create ap_get_server_conf() to call the MPM to fetch a static pointer to server_conf. Now you have
what you need to call ap_log_error(). I've done this and it works fine. Maybe overlooking some other
details.
Bill
Re: logging APR errors
Posted by rb...@covalent.net.
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.
Ryan
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 function
> This is a dirt simple solution that would solve 99% of the cases of interest to Apache.
>
> Bill
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: logging APR errors
Posted by Bill Stoddard <re...@attglobal.net>.
> 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 function
This is a dirt simple solution that would solve 99% of the cases of interest to Apache.
Bill
Re: logging APR errors
Posted by rb...@covalent.net.
> > Many of those functions have
> > multiple error paths. This means that we get multiple if's for every APR
> > function. People are already complaining that APR isn't performance
> > aware, and now we want to slow it down more.
> >
> > The correct way to solve this was put forth about a year and a half ago.
>
> There is more than one 'correct' way to solve this.
>
> >
> > 1) Use a rich error code, which gives all the information we could
> > possibly want. We provided a bitmask that would have worked for these
> > cases.
> >
> > 2) Use the context to return an error string.
> >
> > Both of these were suggested and rejected. I am very much against hacking
> > an error function into APR now.
>
> It's not a hack. You may not like it but that doesn't make it a hack.
It is a hack, because it is the third solution to this problem, and none
of them solve all three conditions. We have the pools errors, the dso
errors, and now an error function.
Exposing the Applications error logging code doesn't solve these
problems. What does that function look like? Is it going to look just
like Apache's error log functions? That ties APR to Apache. If not, then
Apache's logs lose information about when the error happened.
APR needs to be able to return a string to Apache, so that Apache can use
that string in it's logs.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: logging APR errors
Posted by Bill Stoddard <re...@attglobal.net>.
> On Fri, 14 Jul 2000, Bill Stoddard wrote:
> > > On Fri, 14 Jul 2000, Greg Ames wrote:
>
> > > The correct way to handle this was veto'ed at the very beginning of
> > > development for APR. The correct method was to have the status be a
> > > complex bitmap which we could use to determine where we actually failed.
> > >
> > > Since we no longer have that option, we have to define different APR error
> > > codes for the different failure conditions inside of ap_sendfile.
> > >
> >
> > There are other techniques available as well. Look back a couple of months in this list for Jeff
> > Trawick's posts on this exact topic. One method mentioned at the time is to register an
application
> > specifc (Apache in this case, or perhaps an individual MPM) error handling function with APR at
init
> > time. This function is called to log the specific failure (function call, failing system call,
line
> > of code, message string, etc.). If Apache is not interested in greater visability into APR
failures,
> > it simply does not register an error handler function (which implies the APR wrapper that calls
this
> > function must be able to handle a NULL function pointer). This is simple and very extensible.
Make
> > sense?
>
> Take a look at the archives from a year. The decision from back then, was
> to return error values to the calling program. Having every APR program
> be able to register an error logging function adds yet another if
> condition to EVERY single APR function.
No. The function is just a way for APR to get access to the application's error logging. The
function would only be called on the error path to report error conditions to the application. It
would not be called on the non-error path. If the application is not interested in error information
('extended' error information that is, beyond what is returned in ap_status) from APR, then it
doesn't register the handler. This will not impact APRs performance (on the non-error path) by even
one instruction, regardless of whether the handler is registered or not.
> Many of those functions have
> multiple error paths. This means that we get multiple if's for every APR
> function. People are already complaining that APR isn't performance
> aware, and now we want to slow it down more.
>
> The correct way to solve this was put forth about a year and a half ago.
There is more than one 'correct' way to solve this.
>
> 1) Use a rich error code, which gives all the information we could
> possibly want. We provided a bitmask that would have worked for these
> cases.
>
> 2) Use the context to return an error string.
>
> Both of these were suggested and rejected. I am very much against hacking
> an error function into APR now.
It's not a hack. You may not like it but that doesn't make it a hack.
Bill
Re: logging APR errors
Posted by rb...@covalent.net.
This is the exact same design we are using for the failure function for
memory. It requires an 'if' in that code, and it will require and 'if' in
this code. This is the wrong approach. It was the wrong approach for the
pools, but since we were just trying for backwards compatability with
Apache 1.3 pools, I was willing to accept it. I am against it when there
is a perfectly valid design that requires just a bit more code changes,
but works better.
Ryan
On Fri, 14 Jul 2000, Paul J. Reder wrote:
> rbb@covalent.net wrote:
> > ... Having every APR program
> > be able to register an error logging function adds yet another if
> > condition to EVERY single APR function. Many of those functions have
> > multiple error paths. This means that we get multiple if's for every APR
> > function. People are already complaining that APR isn't performance
> > aware, and now we want to slow it down more.
>
> Why does it add if logic to anything. My understanding of this idea is that
> the error handler is initially set to a default APR handler. An api allows
> the user of APR to register an application specific error handler instead.
> If this api is called then the error handler is set to it (replacing the
> previous pointer to the default handler).
>
> When an error occurs, the handler is called - period. No if logic required.
> The error handler always points to a single unambiguous error handling function.
>
> Am I missing something? Did I misunderstand Jeff's design?
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: logging APR errors
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> ... Having every APR program
> be able to register an error logging function adds yet another if
> condition to EVERY single APR function. Many of those functions have
> multiple error paths. This means that we get multiple if's for every APR
> function. People are already complaining that APR isn't performance
> aware, and now we want to slow it down more.
Why does it add if logic to anything. My understanding of this idea is that
the error handler is initially set to a default APR handler. An api allows
the user of APR to register an application specific error handler instead.
If this api is called then the error handler is set to it (replacing the
previous pointer to the default handler).
When an error occurs, the handler is called - period. No if logic required.
The error handler always points to a single unambiguous error handling function.
Am I missing something? Did I misunderstand Jeff's design?
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: logging APR errors
Posted by rb...@covalent.net.
On Fri, 14 Jul 2000, Bill Stoddard wrote:
> > On Fri, 14 Jul 2000, Greg Ames wrote:
> > The correct way to handle this was veto'ed at the very beginning of
> > development for APR. The correct method was to have the status be a
> > complex bitmap which we could use to determine where we actually failed.
> >
> > Since we no longer have that option, we have to define different APR error
> > codes for the different failure conditions inside of ap_sendfile.
> >
>
> There are other techniques available as well. Look back a couple of months in this list for Jeff
> Trawick's posts on this exact topic. One method mentioned at the time is to register an application
> specifc (Apache in this case, or perhaps an individual MPM) error handling function with APR at init
> time. This function is called to log the specific failure (function call, failing system call, line
> of code, message string, etc.). If Apache is not interested in greater visability into APR failures,
> it simply does not register an error handler function (which implies the APR wrapper that calls this
> function must be able to handle a NULL function pointer). This is simple and very extensible. Make
> sense?
Take a look at the archives from a year. The decision from back then, was
to return error values to the calling program. Having every APR program
be able to register an error logging function adds yet another if
condition to EVERY single APR function. Many of those functions have
multiple error paths. This means that we get multiple if's for every APR
function. People are already complaining that APR isn't performance
aware, and now we want to slow it down more.
The correct way to solve this was put forth about a year and a half ago.
1) Use a rich error code, which gives all the information we could
possibly want. We provided a bitmask that would have worked for these
cases.
2) Use the context to return an error string.
Both of these were suggested and rejected. I am very much against hacking
an error function into APR now. I would rather delay 2.0, and put in the
correct solution (one of the two above), than hack in the wrong solution.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: logging APR errors
Posted by Bill Stoddard <re...@attglobal.net>.
> On Fri, 14 Jul 2000, Greg Ames wrote:
>
> > I got the following while trying to get mod_file_cache working on Linux:
> >
> > [Tue Jul 04 17:13:59 2000] [error] [client 127.0.0.1] (22)Invalid
> > argument: mod_file_cache: iol_sendfile failed.
> >
> > Can you tell what failed without running a debugger?
> >
> > This doesn't even point me to the failing file. But that part is easy -
> > you know it's Linux, so iol_sendfile always invokes ap_sendfile. If you
> > go there, you will see 7 syscalls or APR calls for the current Linux
> > flavor. So which one failed?
> >
> > Unfortunately, most of these 7 are network related which means they
> > could fail in production. There's gotta be a better way. I have some
> > thoughts but would like to hear other opinions first.
>
> The correct way to handle this was veto'ed at the very beginning of
> development for APR. The correct method was to have the status be a
> complex bitmap which we could use to determine where we actually failed.
>
> Since we no longer have that option, we have to define different APR error
> codes for the different failure conditions inside of ap_sendfile.
>
There are other techniques available as well. Look back a couple of months in this list for Jeff
Trawick's posts on this exact topic. One method mentioned at the time is to register an application
specifc (Apache in this case, or perhaps an individual MPM) error handling function with APR at init
time. This function is called to log the specific failure (function call, failing system call, line
of code, message string, etc.). If Apache is not interested in greater visability into APR failures,
it simply does not register an error handler function (which implies the APR wrapper that calls this
function must be able to handle a NULL function pointer). This is simple and very extensible. Make
sense?
Bill (who is going to beach RSN :-)
Re: logging APR errors
Posted by rb...@covalent.net.
On Fri, 14 Jul 2000, Greg Ames wrote:
> I got the following while trying to get mod_file_cache working on Linux:
>
> [Tue Jul 04 17:13:59 2000] [error] [client 127.0.0.1] (22)Invalid
> argument: mod_file_cache: iol_sendfile failed.
>
> Can you tell what failed without running a debugger?
>
> This doesn't even point me to the failing file. But that part is easy -
> you know it's Linux, so iol_sendfile always invokes ap_sendfile. If you
> go there, you will see 7 syscalls or APR calls for the current Linux
> flavor. So which one failed?
>
> Unfortunately, most of these 7 are network related which means they
> could fail in production. There's gotta be a better way. I have some
> thoughts but would like to hear other opinions first.
The correct way to handle this was veto'ed at the very beginning of
development for APR. The correct method was to have the status be a
complex bitmap which we could use to determine where we actually failed.
Since we no longer have that option, we have to define different APR error
codes for the different failure conditions inside of ap_sendfile.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------