apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] clean up debug patch used with Apache 2 on daedalus
Date Fri, 21 Feb 2003 19:27:08 GMT
Joe Orton wrote:

> On Fri, Feb 21, 2003 at 07:58:16AM -0500, Jeff Trawick wrote:
>
> >Joe Orton wrote:


> >>Surely this can be done already outside APR?
> >
> >Joe, what is it you really want to say :)  I think we all know the
> >answer to that question already.
>
>
> Just seems like classic creeping featurism to me...  will you duplicate
> this in the every socket_recv implementation, for example.


theoretically easier to duplicate in every socket_recv than in every APR 
app (not that many would really care)

>   Sounds like
> a good idea for a filter though ;)

not suitable for me, since I assume from the start that filters are 
going to be part of the problem, so I need to be outside of the scope of 
filtering :)

and yes, I have used filter-based trace mechanisms (mod_ext_filter+tee 
is my current favorite for output, though I once wrote a filter-based 
module for Apache to trace what was passed from one filter to another)

--/--

Certainly I don't consider this a required or even a pleasant addition 
to APR, but it has proven very useful for Apache in the past, and 
keeping it from being generally available is uncool.

[By the way Joe, I don't mean anything in the following to express 
negative feelings towards your negative feelings on my patch, or towards 
negative feelings previously expressed at some of the other patches 
mentioned below.  I really do respect the issues and don't pretend there 
is some obvious answer.]

I find the issue of code serviceability vs. code maintainability pretty 
interesting.  There is a certain amount of serviceability you get for 
free on Unix (packet traces, backtraces on active processes, system call 
traces, kernel traces, core dumps), and you don't have to clutter your 
code to take advantage of it.  As long as the Unix variant has the right 
tools (not all do) and the user has the right skills (not all do), the 
vast majority of problems can eventually be solved without cluttering 
the code with trace capability and saving footprints or other data in 
case of an exception.

If your Unix variant is missing some diagnostic features or you don't 
have the skills or you want to debug the problem very quickly, then you 
are broken, and need something more.  Note that one of these conditions 
is always true when time is money and the transactions going through the 
server are actually important.

I posted a patch a day or so to dev@httpd to call a hook from 
sig_coredump.  Several people indicated strong displeasure at it but 
gave no concrete objections.  To hell with that...  I'm sticking it in 
the version of Apache "we at the office" support and when somebody comes 
to my office bemoaning the fact that there is a problem getting the 
right info at the time of the SIGWHATEVER I'll grin and start whipping 
up something the customer can LoadModule into their server to make it 
happen.

Many moons ago Bill Stoddard posted a patch to add socket IOLs to APR. 
I tried to convince folks that it was great for adding tracing to APR 
apps.  But it was not strictly necessary and Apache filtering was really 
the right way to go and whatever else.  To hell with that...  It is in 
the version of Apache we support and when customers have some types of 
problems I don't care whether they can spell tcpdump or can get a 
working version or I can figure out the right incantation to avoid 
superfluous information in the output or even if the customer is willing 
to install such code on their box.  Instead, I give them a network trace 
module for the version of Apache we support that lets them easily 
capture the right stuff with no command-line hocus pocus.

Any Unix kernel routine on OS/390 a.k.a. z/OS sets a secondary error 
code that encapsulates the source code module that set the error and 
usually something more finely-grained the errno that tells what went 
wrong.  You or I can't do much with the source code module but there are 
people I know that can.  The finely-grained error code is documented. 
Many moons ago I suggested a mechanism in APR such that apps could find 
out any such extra information for the kernel routine that caused the 
APR function to fail (not necessarily the last kernel routine APR called 
before returning).  But this was too ugly or cluttering or some such. 
(I bet you'll guess the next part.)  To hell with that...  If I ever 
have to support Apache on that OS you bet we won't be losing that info, 
at least for the common points of failure.)

Oh, I almost forgot.  Our customers are running with the daedalus patch too.

I'm tickled that we can add serviceability aids to the version of Apache 
that we support without breaking binary compatibility with unpatched APR 
and unpatched Apache, but it really is a bummer not to share* and it is 
a bummer not to have a richer community to make it work cleaner/better 
and it is a bummer that it would be hard for j random user to make use 
of some of the tools (first apply patch from some non-ASF location and 
then rebuild everything).  Perhaps what is needed is for some related 
project to maintain such patches along with appropriate documentation.

Enough rambling :)

*"not to share" is a bit strong...  our Apache2-based server is freely 
available for download and the modifications made to pure Apache2+APR 
are provided in a patch file that gets installed...  but that isn't what 
I usually mean by sharing code :)




Mime
View raw message