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 [EMAIL PROTECTED] 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 :)
