Greg Hudson wrote:
>On Tue, 2004-05-18 at 17:52, Branko Čibej wrote:
>
>
>>You'll have to be a bit more persuasive than that. Either you use them
>>in the logging implementation, or in the code, or in syslog, or
>>wherever. Bout you can't reasonably avoid them in this case. Note that
>>the problem with golobal variables is when they're in a (possibly
>>shared) library. In this case, it's one variable in svnserve, we can
>>ensure single-threaded initialization, and it's readonly from that point
>>onwards.
>>
>>
>
>It's bad design wherever you put them (except when you really can't
>avoid it, like signal handlers). Perhaps people will want different
>logging levels for different repositories, and global variables prohibit
>that.
>
>We have this nice driver-state structure in svnserve. No reason not to
>use it.
>
>
Point taken.
>>Evaluating the logging level is not the issue. Evaluating the function
>>parameters during the call _is_. I don't have numbers handy, but believe
>>me, I know from personal experience that it _can_ become an issue when
>>the logging is verbose enough.
>>
>>
>
>Show me any place where there's any reason to evaluate a function (cheap
>or expensive) in the arguments to the log function.
>
>
We'll see, won't we?
>For that matter, show me a logging system in wide use which doesn't make
>this "basic mistake."
>
>
That's why servers usually don't provide really verbose logging, at
least by default -- which makes obscure,
platform-and-configuration-related problems very hard to reproduce and
debug.
>>If the logging isn't even potentially
>>verbose enough for this to matter, then it's also next to useless for
>>locating bugs.
>>
>>
>
>This is the third time I've said it, without acknowledgement from you:
>without invading the libraries, we could put log calls between every two
>lines of code in svnserve and it would still be totally useless for
>finding most bugs, including the one which triggered this thread.
>svnserve is only 1500 lines of code, with 50,000 lines of library code
>behind it. The deepest you're going to get is stuff like, "this client
>issued this top-level RA request," which might sometimes help you
>reproduce the bug, at most.
>
>
Ah, you don't suppose I'm going to be happy until we have logging
support in the libraries themselves, do you? Svnserve is just the first
step, and indeed it can't tell you very much. Unfortunately we can't
even begin to think about adding tracing to the libraries until we
introduce library initialisation functions, therefore not before 2.0.
There are in fact two kinds of logging that I like to treat separately:
* Activity logs, such as httpd provides. Plain function calls an log
level checks within the function are good enough for that, because
no logging call is in the critical path.
* Debugging traces, which in my experience are the _only_ way to
reliably diagnose server problems in client installations. The
quality of such a log depends on its verbosity and the precision
with which you can control its output, and plain function calls
simply are not good enough for that.
>>All in all, I'd prefer to go with a mature library like log4c because
>>it gives us lots of control over the output format, output location,
>>logging levels, and such.
>>
>>
>What makes you say log4c is a "mature library?" The version number?
>Its web page calls it a work in progress, and claims it has never been
>compiled on a *BSD. It's not vaguely portable.
>
"Like" log4c feature-wise. I do have my own logging library that's been
used successfully in long-running high-load servers, and BTW can be much
more finely controlled than log4[jc] in terms of output verbosity. I
didn't want to bring that up here because it's only necessary for debug
traces, and as I said above, we won't have those before 2.0.
>It requires expat, which stinks of severe overengineering.
>
>
You're very fond of that term, aren't you. :-) If you've never tried to
write a general-purpose logging library, it's perhaps not so obvious
that it must be easily configurable. If log4c follows log4j, then the
XML configuration is optional. I've not looked at the code, though.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 19 08:05:19 2004