You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2004/05/18 01:49:48 UTC
Svnserve still exiting randomly in threaded mode
Whilst trying to reproduce the problem in issue #1862, I noticed that
svnserve on Windows still terminates after an error (I'm assuming the
same would happen on Linux in threaded mode). This time the repro was as
follows (using cygwin's bash, obviously):
$ svnadmin create repo-template
$ vi repo-template/conf/svnserve.conf
(set anon-access to write)
$ cp -R repo-template repo
$ svnserve -d -r repo &
[repeat several times...
$ svn co svn://localhost wc1
Checked out revision 0.
$ svn co svn://localhost wc2
Checked out revision 0.
$ cd wc1
$ echo 'contents' > foo.txt
$ svn add foo.txt
A foo.txt
$ svn ci -m ''
Adding foo.txt
Transmitting file data .
Committed revision 1.
$ cd ../wc2
$ echo 'other contents' > foo.txt
$ svn up
svn: Failed to add file 'foo.txt': object of the same name already exist
$ cd ..
$ rm -fr repo
$ cp -R repo-template repo
...now forget to remove wc1 and wc2 before repeating]
$ svn co svn://localhost wc1
svn: Reference to non-existent revision '1' in filesystem
'C:/Home/brane/src/svn/scratch/r/db'
[1]+ Exit 58 svnserve -d -r repo
Now, this falls into the "don't do this" class, and the crash doesn't
happen consistently (I repeated this several times, usually remembering
to delete wc1 and wc2 before checking out again). However, my assessment
at this point is that:
* Threaded svnserve is too flaky for a production environment, and
we should not recommend to use svnserve on Windows the way it
stands now
* The fact that svnserve does not do any logging is a big problem here
My best guess is that #1862 is somehow connected to threaded svnserve
instability; it seems that /all/ the reports were about svnserve!
I think we need to put a pretty hugh priority on stabilizing threaded
svnserve, and adding server-side logging. Other problems aside, a server
that doesn't produce logs is simply not ready for serious usage.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Branko Čibej wrote:
>
>> I think we need to put a pretty hugh priority on stabilizing threaded
>> svnserve, and adding server-side logging. Other problems aside, a
>> server that doesn't produce logs is simply not ready for serious usage.
>
>
> I was actually thinking about giving this a go myself. I want to run
> svnserve under daemontools (actually, I am already doing that, just
> not getting any logs), so I'd be a prime candidate to do this work.
>
> Do I really have to implement a syslog-style interface, or can I just
> add a new commandline switch that spews logs on STDOUT (which is all I
> need)? If the former, I'll have to do the latter anyways.
I think so...stdout wouldn't work under inetd, for example.
> I assume the Win32 interface is going to have to use the Event Log in
> either case.
Oh no! The event log tends to fill up too quickly. Apache logs to a file
on Windows, and I think that would be appropriate for svnserve. I don't
know about log rotation, though; I suspect Apache does its own, because
there's no logrotate daemon on Windows.
I wonder if we couldn't just rip the logging logic out of httpd, and of
course simplify it. And put the configuration in
repo/conf/svnserve.conf, I expect, and also a global config file
(/etc/svn/svnserve?)/
> Anyone want to nominate /how much/ logging happens (comparable to the
> HTTP logging or less chatty)? Do we want
>
> 1) logs
> 2) verbose logs
> 3) really compulsive debugging logs
>
> as seperate levels of logging?
Yes, yes and yes. I'd call that: error, info, and debug. Only errors go
to the error log; all actions, including errors, go to the info log; and
the debug log is for helping reproduce an error and should be turned off
by default.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
> I think we need to put a pretty hugh priority on stabilizing threaded
> svnserve, and adding server-side logging. Other problems aside, a server
> that doesn't produce logs is simply not ready for serious usage.
I was actually thinking about giving this a go myself. I want to run svnserve
under daemontools (actually, I am already doing that, just not getting any
logs), so I'd be a prime candidate to do this work.
Do I really have to implement a syslog-style interface, or can I just add a new
commandline switch that spews logs on STDOUT (which is all I need)? If the
former, I'll have to do the latter anyways. I assume the Win32 interface is
going to have to use the Event Log in either case.
Anyone want to nominate /how much/ logging happens (comparable to the HTTP
logging or less chatty)? Do we want
1) logs
2) verbose logs
3) really compulsive debugging logs
as seperate levels of logging?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
> John Peacock wrote:
>> I will also look seriously at the Apache log code (since that can
>> support pipes) and wouldn't require another library.
>
>
> Yes it will, because that code is not in APR, AFAIK.
>
OK, another library that we aren't already familiar with. If I wind up
extracting the log system from Apache, there is probably a chance that it
_would_ be included in a future APR.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> I'll take a look at log4c, but as I said, I will be running svnserve
> under daemontools, so there will also be a way to log to STDERR/STDOUT.
That's fine.
> I will also look seriously at the Apache log code (since that can
> support pipes) and wouldn't require another library.
Yes it will, because that code is not in APR, AFAIK.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
>> Uh, do you have any evidence for that statement? I've seen a lot of
>> poor incarnations of malloc wrappers and text editors and GUI toolkits,
>> but not so many bad logging libraries.
>>
>>
> I've seen lots and lots. :-)
Yeah, and unfortunately, syslog is a prime example. :-)
Luckily for us, I think svnserve won't be too likely to trigger syslog's
failings (high CPU usage, dropping lines under high load, filling up the
filesystem with logfiles).
>> I'm particularly concerned with log4c's invention of a new log4rc config
>> file, when Unix already has a perfectly good (well, perfectly adequate)
>> central logging configuration file.
>>
>>
> You don't have to use that configuratin file. If you want to keep things
> simple, you can do all the initialization programatically (which would
> make sense for svnserve, anyway).
I'll take a look at log4c, but as I said, I will be running svnserve under
daemontools, so there will also be a way to log to STDERR/STDOUT. I will also
look seriously at the Apache log code (since that can support pipes) and
wouldn't require another library.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Branko Čibej wrote:
>
>> The first mistake everybody seems to make is to forget that parameter
>> evaluation takes time, so they put debug level checks into the
>> logging functions themselves. You wouldn't _balieve_ the kind of
>> slowdown this can cause.
>
>
> Could you elaborate on this a little? I'm not sure I know what you
> are referring to.
>
> I believe there are two major ways to structure log code (ignoring
> compile-time #ifdef):
>
> 1) Anywhere you want to log something, call a common log routine with
> a log type (error, info, and debug) and a message; the log routine the
> decides what to send where;
>
> 2) Anywhere you want to log something, call a specific routine for the
> type of log message;
>
> In both cases, the call to the logger routine should be wrapped by a
> check against a global loglevel variable.
>
> if ( loglevel > 0 ) /* log everything */ {log_this(DEBUG,"message")}
> if ( loglevel == 1 ) /* log info only */ {log_this(INFO,"message")}
>
> Is this last point what you were worried about? Some of that could
> even be hidden by a macro.
>
> I would prefer to use the 1st mode above, as it makes for a slightly
> cleaner interface and makes it much easier to have a single output
> stream (if so desired).
Now you're scaring me. I wrote two logging libraries for in-house use,
and it seems that you're just starting to struggle with the basics. :-)
The first most common mistake is to do this:<>
<><> void logger(int level, const char *format, ...) {
if (level > global_log_level)
/* do your stuff */
}
<><><>The reason why this is a problem is that the message parameters
are evaluated at the point of call, regardless of the value of
global_log_level. This is clearly bad.
As you noted correctly, the log level check must be done at the call
point, in such a way that you avoid evaluating the parameters. If you
have a printf-like logger, as above, and don't have C99 with vararg
macros, you usually do something like this:
void logger (const char *format, ...);
#define LOG(lvl, args) \
((lvl) > global_log_level ? logger args : (void)0)
//...
LOG(INFO, ("this is number %d", some_expensive_function()));
This will avoid calling some_expensive_function if the INFO level isn't
turned on, but will incur the cost of reading from the global variable
if you do it often (and I believe compilers typically won't store the
value in a register).
You can avoid _that_ cost by adding a LOG_INIT macro that copies the
global value to the stack, e..g,
#define LOG_INIT() const int local_log_level = global_log_level
You then put LOG_INIT at the start of each function, and use
local_log_level in the LOG macro.
Things become more interesting when you want to also trace function
execution. I can show you an example of how that's done efficiently, but
that's really not _that_ important for svnserve.
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. Pulling the logging logic out of httpd and
dumping it into APR(-util?) may be appropriate, although probably less
flexible.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> I'm not sure what you mean here. svn_error_createf() does not make the
> caller responsible for constructing a single string.
Nevermind, apparently I was thinking of some other program. ;~)
This code:
return svn_error_createf (SVN_ERR_RA_ILLEGAL_URL, NULL,
"'%s'\n"
"is not the same repository as\n"
"'%s'", url, rbaton->session->repos_url);
(from libsvn_ra_local/ra_plugin.c) is exactly what you are talking about, right?
I can do that... ;~)
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-05-18 at 15:38, John Peacock wrote:
> I'm going to have a look at the logging in the ra_dav code, because if I'm not
> mistaken, the log messages will have a variable number of arguments depending on
> the exact thing being logged. Are you suggesting that the caller pass a format
> string and an array of arguments and the logger function puts it together?
Yes. (Well, not an array of arguments; a variable number of arguments.)
> From what I remember of the places I saw svn_error_createf() being used, the
> /caller/ was responsible for constructing the single string which was passed up
> the chain. Is that not the model that would normally be followed?
I'm not sure what you mean here. svn_error_createf() does not make the
caller responsible for constructing a single string.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> Constructing strings? Why would you have to construct any strings
> specifically for logging? The final assembly would presumably be done
> printf-style within the log function, and the arguments should generally
> be ready-made.
>
I'm going to have a look at the logging in the ra_dav code, because if I'm not
mistaken, the log messages will have a variable number of arguments depending on
the exact thing being logged. Are you suggesting that the caller pass a format
string and an array of arguments and the logger function puts it together?
From what I remember of the places I saw svn_error_createf() being used, the
/caller/ was responsible for constructing the single string which was passed up
the chain. Is that not the model that would normally be followed?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-05-18 at 14:12, John Peacock wrote:
> I'm not micromanaging cycles by refusing to make an expensive call (especially
> constructing strings) if I can short circuit via a test; that's just good
> programming.
Constructing strings? Why would you have to construct any strings
specifically for logging? The final assembly would presumably be done
printf-style within the log function, and the arguments should generally
be ready-made.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> I think he meant that debug-level logs should use a macro which
> evaluates to nothing if a compile-time flag isn't turned on.
OK, that I'll buy as a reasonable argument.
>
> I don't believe that it matters, unless you've put a debug log inside a
> tight loop (like the core of the vdelta loop). And I continue to
> believe that debug-level logs are a bad idea, because (a) they clutter
> the code, and (b) we can't easily put them in the libraries, and without
> that they don't do any good.
I think you are imaging a much deeper level of debug than I am certainly
thinking about. I have to look at how the Apache ra_dav logs are structured,
but I wouldn't think we should go any deeper than "so and so asked for this
file" not all of the internal code on actually processing the file from the
database (for example).
Ideally, whatever gets currently gets logged with ra_dav should be similarly
logging using ra_svn.
>
> -1 on using global variables.
That was pseudo-code; there is going to be some way of evaluating whether
logging has been requested at all. It doesn't have to be a "global variable"
but it does have to be accessible globally.
>
> And, once again, stop with the damn cycle micromanagement. Unless you
> have a benchmark showing measurably worse performance from evaluating
> the log level inside the logging function, don't clutter up the caller,
> macros or no.
>
It's not the evaluation that is the issue; it is the dispatch expense of calling
a log function only to ignore the output. Perhaps my example left the wrong
impression; I'm suggesting only that the log routines should not be called if
logging isn't even turned on.
I'm not micromanaging cycles by refusing to make an expensive call (especially
constructing strings) if I can short circuit via a test; that's just good
programming.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
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
Re: Svnserve still exiting randomly in threaded mode
Posted by Greg Hudson <gh...@MIT.EDU>.
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.
> 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.
For that matter, show me a logging system in wide use which doesn't make
this "basic mistake."
> 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.
> 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. It requires expat,
which stinks of severe overengineering.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>-1 on using global variables.
>
>
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.
>And, once again, stop with the damn cycle micromanagement. Unless you
>have a benchmark showing measurably worse performance from evaluating
>the log level inside the logging function, don't clutter up the caller,
>macros or no.
>
>
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. If the logging isn't even potentially
verbose enough for this to matter, then it's also next to useless for
locating bugs. You want to be able to tell a user whose bug you can't
reproduce to turn on maximum logging and try again. If the issue isn't
triggered by timing, you've got a much better chance to spot the bug
from reading the logs than you'd ever be able to do with a debugger.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Tue, 2004-05-18 at 13:43, John Peacock wrote:
>
>
>>Could you elaborate on this a little? I'm not sure I know what you are
>>referring to.
>>
>>
>
>I think he meant that debug-level logs should use a macro which
>evaluates to nothing if a compile-time flag isn't turned on.
>
>
No I didn't mean that at all. Never, _ever_ disable logging with a
compile-time flag! Your user won't be able to switch it on when they
need it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-05-18 at 13:43, John Peacock wrote:
> Could you elaborate on this a little? I'm not sure I know what you are
> referring to.
I think he meant that debug-level logs should use a macro which
evaluates to nothing if a compile-time flag isn't turned on.
I don't believe that it matters, unless you've put a debug log inside a
tight loop (like the core of the vdelta loop). And I continue to
believe that debug-level logs are a bad idea, because (a) they clutter
the code, and (b) we can't easily put them in the libraries, and without
that they don't do any good.
> In both cases, the call to the logger routine should be wrapped by a check
> against a global loglevel variable.
>
> if ( loglevel > 0 ) /* log everything */ {log_this(DEBUG,"message")}
> if ( loglevel == 1 ) /* log info only */ {log_this(INFO,"message")}
-1 on using global variables.
And, once again, stop with the damn cycle micromanagement. Unless you
have a benchmark showing measurably worse performance from evaluating
the log level inside the logging function, don't clutter up the caller,
macros or no.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
> The first mistake everybody seems to make is to forget that parameter
> evaluation takes time, so they put debug level checks into the logging
> functions themselves. You wouldn't _balieve_ the kind of slowdown this
> can cause.
Could you elaborate on this a little? I'm not sure I know what you are
referring to.
I believe there are two major ways to structure log code (ignoring compile-time
#ifdef):
1) Anywhere you want to log something, call a common log routine with a log type
(error, info, and debug) and a message; the log routine the decides what to send
where;
2) Anywhere you want to log something, call a specific routine for the type of
log message;
In both cases, the call to the logger routine should be wrapped by a check
against a global loglevel variable.
if ( loglevel > 0 ) /* log everything */ {log_this(DEBUG,"message")}
if ( loglevel == 1 ) /* log info only */ {log_this(INFO,"message")}
Is this last point what you were worried about? Some of that could even be
hidden by a macro.
I would prefer to use the 1st mode above, as it makes for a slightly cleaner
interface and makes it much easier to have a single output stream (if so desired).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Tue, 2004-05-18 at 00:42, ectosphenoid-svn@yahoo.com wrote:
>
>
>>>>Appears to require gcc, and not work on Windows currently. And
>>>>really, logging isn't a big enough problem to justify a new library
>>>>dependency. Adding a bit of code to APR (perhaps ripped from the
>>>>still-bleeding heart of httpd's server/log.c) seems like the optimal
>>>>solution.
>>>>
>>>>
>>People who try to reinvent logging libraries are doomed to do so poorly.
>>
>>
>
>Uh, do you have any evidence for that statement? I've seen a lot of
>poor incarnations of malloc wrappers and text editors and GUI toolkits,
>but not so many bad logging libraries.
>
>
I've seen lots and lots. :-)
The first mistake everybody seems to make is to forget that parameter
evaluation takes time, so they put debug level checks into the logging
functions themselves. You wouldn't _balieve_ the kind of slowdown this
can cause.
>I'm particularly concerned with log4c's invention of a new log4rc config
>file, when Unix already has a perfectly good (well, perfectly adequate)
>central logging configuration file.
>
>
You don't have to use that configuratin file. If you want to keep things
simple, you can do all the initialization programatically (which would
make sense for svnserve, anyway).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-05-18 at 00:42, ectosphenoid-svn@yahoo.com wrote:
> >> Appears to require gcc, and not work on Windows currently. And
> >> really, logging isn't a big enough problem to justify a new library
> >> dependency. Adding a bit of code to APR (perhaps ripped from the
> >> still-bleeding heart of httpd's server/log.c) seems like the optimal
> >> solution.
>
> People who try to reinvent logging libraries are doomed to do so poorly.
Uh, do you have any evidence for that statement? I've seen a lot of
poor incarnations of malloc wrappers and text editors and GUI toolkits,
but not so many bad logging libraries.
I'm particularly concerned with log4c's invention of a new log4rc config
file, when Unix already has a perfectly good (well, perfectly adequate)
central logging configuration file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by ec...@yahoo.com.
>> Appears to require gcc, and not work on Windows currently. And
>> really, logging isn't a big enough problem to justify a new library
>> dependency. Adding a bit of code to APR (perhaps ripped from the
>> still-bleeding heart of httpd's server/log.c) seems like the optimal
>> solution.
People who try to reinvent logging libraries are doomed to do so poorly.
> Oh, I suppose so. I suggested log4c because I'm very happy with
> log4j, and log4c seems to be a straight port. The GCC dependency
> and not running on Windows shouldn't be hard to fix.
I am also quite happy with log4j. Its a shame the ports for other
languages have some not-so-nice things about them.
I think using a logging library would be wonderful. It would take time
inserting the statements into the code but once that pain is over its all
good.
I'll go back to lurking now.
Michael Price
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Mon, 2004-05-17 at 22:34, Branko Čibej wrote:
>
>
>>Yes... I can't reproduce it either. It's horrible, really :-( In my
>>experience, logging to a file is the best way to find these bugs.
>>
>>
>
>Why do people say such nice things about Windows development tools when
>they can't seem to help with the most basic of debugging tasks?
>
>
Which people? :-)
>>I don't think it would be very hard to reproduce syslog behavious on
>>Windows. Actually, I'd be against reinventing the wheel here, and just
>>use log4c (http://log4c.sourceforge.net/). I think it can use syslog on
>>Unix automagically.
>>
>>
>
>Appears to require gcc, and not work on Windows currently. And really,
>logging isn't a big enough problem to justify a new library dependency.
>Adding a bit of code to APR (perhaps ripped from the still-bleeding
>heart of httpd's server/log.c) seems like the optimal solution.
>
>
Oh, I suppose so. I suggested log4c because I'm very happy with log4j,
and log4c seems to be a straight port. The GCC dependency and not
running on Windows shouldn't be hard to fix.
>>>and partly because I have no idea how to locate a global
>>>configuration file under Windows.
>>>
>>>
>>Of course we do.
>>
>>
>
>I said *I* didn't. I didn't say *we* didn't. :)
>
>
Ah! Semantic details. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-05-17 at 22:34, Branko Čibej wrote:
> Yes... I can't reproduce it either. It's horrible, really :-( In my
> experience, logging to a file is the best way to find these bugs.
Why do people say such nice things about Windows development tools when
they can't seem to help with the most basic of debugging tasks?
> I don't think it would be very hard to reproduce syslog behavious on
> Windows. Actually, I'd be against reinventing the wheel here, and just
> use log4c (http://log4c.sourceforge.net/). I think it can use syslog on
> Unix automagically.
Appears to require gcc, and not work on Windows currently. And really,
logging isn't a big enough problem to justify a new library dependency.
Adding a bit of code to APR (perhaps ripped from the still-bleeding
heart of httpd's server/log.c) seems like the optimal solution.
> >and partly because I have no idea how to locate a global
> >configuration file under Windows.
> Of course we do.
I said *I* didn't. I didn't say *we* didn't. :)
> We user /etc/svn on Unix, "$ALLUSERSPROFILE/Application Data/Subversion"
> and the global registry on Windows.
Okay.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Mon, 2004-05-17 at 21:49, Branko Čibej wrote:
>
>
>> * The fact that svnserve does not do any logging is a big problem here
>>
>>
>
>Any ideas on how we should implement a portable logging primitive? I
>feel like it's our responsibility to use syslog() by default on Unix,
>but obviously that's not portable to Windows. httpd isn't much of an
>example; I think it only believes in logging to a file under the server
>root, which isn't a concept we have.
>
>
Supporting syslog() on Unix would be nice, as well as logging to a file
on both platforms. We don't need a server root, just a log file
directory for that. Picking a default wouldn't be that hard; $prefix/log
is the obvious choice on both Unix and Windows. We would have to
introduce a global svnserve config file, though.
>>I think we need to put a pretty hugh priority on stabilizing threaded
>>svnserve, and adding server-side logging.
>>
>>
>
>Much as I'd like to have server-side logging, I don't see how it's
>connected to the other problem. The process died (with status 58, which
>is weird--I don't think any part of our code exits with any status other
>than 0 or 1), and you'll need a debugger to figure out why.
>
>
That's true...
>(Unless you mean server-side logging at the level of printf debugging.
>That seems excessive.)
>
>
Oh, I do think we should have debug-level logging, but not turned on by
default.
>>(I'm assuming the same would happen on Linux in threaded mode)
>>
>>
>
>I can't make it happen. The odd exit status makes me think the problem
>is somewhere deep and Windows-specific, which means I can't help much.
>
>
Yes... I can't reproduce it either. It's horrible, really :-( In my
experience, logging to a file is the best way to find these bugs.
>John Peacock wrote:
>
>
>>or can I just add a new commandline switch that spews logs on STDOUT
>>(which is all I need)?
>>
>>
>
>Well, I don't think we'd have anything very useful if that's all we did,
>but it would be something.
>
>
>
>>Anyone want to nominate /how much/ logging happens [...]?
>>
>>
>
>syslog has a good mechanism for this, and I'd like to use it if the
>Windows equivalent isn't too screwy.
>
>
I don't think it would be very hard to reproduce syslog behavious on
Windows. Actually, I'd be against reinventing the wheel here, and just
use log4c (http://log4c.sourceforge.net/). I think it can use syslog on
Unix automagically.
>I'm not really keen on having "really compulsive debugging logs"
>cluttering up our code, particularly because we'd have to delve into the
>library code before it would be very useful. Informational logs on what
>client requests are being performed is as deep as I'd like to go.
>
>Branko wrote:
>
>
>>and also a global config file (/etc/svn/svnserve?)/
>>
>>
>
>We don't have a global svnserve config file. Partly because it's
>simpler to declare that all configuration happens at the repository
>level,
>
Well, logging could be an exception...
>and partly because I have no idea how to locate a global
>configuration file under Windows.
>
Of course we do. All other command-line tools understand system-wide
configuration on Windows, svnserve doesn't need to be any different. The
mechanism is already in our code.
>(httpd, once again, went its own route and invented the "conf" subdir of the server root.)
>
>
We user /etc/svn on Unix, "$ALLUSERSPROFILE/Application Data/Subversion"
and the global registry on Windows.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Svnserve still exiting randomly in threaded mode
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-05-17 at 21:49, Branko Čibej wrote:
> * The fact that svnserve does not do any logging is a big problem here
Any ideas on how we should implement a portable logging primitive? I
feel like it's our responsibility to use syslog() by default on Unix,
but obviously that's not portable to Windows. httpd isn't much of an
example; I think it only believes in logging to a file under the server
root, which isn't a concept we have.
> I think we need to put a pretty hugh priority on stabilizing threaded
> svnserve, and adding server-side logging.
Much as I'd like to have server-side logging, I don't see how it's
connected to the other problem. The process died (with status 58, which
is weird--I don't think any part of our code exits with any status other
than 0 or 1), and you'll need a debugger to figure out why.
(Unless you mean server-side logging at the level of printf debugging.
That seems excessive.)
> (I'm assuming the same would happen on Linux in threaded mode)
I can't make it happen. The odd exit status makes me think the problem
is somewhere deep and Windows-specific, which means I can't help much.
John Peacock wrote:
> or can I just add a new commandline switch that spews logs on STDOUT
> (which is all I need)?
Well, I don't think we'd have anything very useful if that's all we did,
but it would be something.
> Anyone want to nominate /how much/ logging happens [...]?
syslog has a good mechanism for this, and I'd like to use it if the
Windows equivalent isn't too screwy.
I'm not really keen on having "really compulsive debugging logs"
cluttering up our code, particularly because we'd have to delve into the
library code before it would be very useful. Informational logs on what
client requests are being performed is as deep as I'd like to go.
Branko wrote:
> and also a global config file (/etc/svn/svnserve?)/
We don't have a global svnserve config file. Partly because it's
simpler to declare that all configuration happens at the repository
level, and partly because I have no idea how to locate a global
configuration file under Windows. (httpd, once again, went its own
route and invented the "conf" subdir of the server root.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org