[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: libsvn_repos logging -- design problems

From: John Peacock <jpeacock_at_rowman.com>
Date: 2005-07-15 17:53:14 CEST

Ben Collins-Sussman wrote:
> * PROBLEM: lots of processes all trying to write to logfiles.
>
> How do we mediate write access to a single logfile with N processes
> all trying to write to it at once?
>
> Possible Solutions?
>
> flock() style stuff, like the 'write lock' in FSFS?

I think the public API is too low level to begin with. Each process
should be calling a logger, which is the only code that handles writing
and the only code which knows to where the log is being written. This
proposed API automatically assumes that there are two streams that are
being written to (error and access) all the time, so it becomes harder
to create different backends. For example, I may want all security logs
to go one place (so I can scan for soon to expire certificates) and
combine all of the error logs for the server in one place, yet have
access be segregated by repository.

It would also solve the apr_psprintf performance issues if there was an
opaque logger object that contained the loglevel, so that all code could
do something like this [horrible pseudocode]:

     if this_event_level < logger.loglevel
         logger.log_error(moderately expensive apr_psprintf)

thus making it completely natural to avoid a potentially expensive test,
as well as remove the need for each place to cache the loglevel
individually.

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
Received on Fri Jul 15 17:53:30 2005

This is an archived mail posted to the Subversion Dev mailing list.