qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kim van der Riet <kim.vdr...@redhat.com>
Subject Re: Proposed qpid logging API
Date Wed, 09 May 2007 11:53:51 GMT
Two silly questions:

1. What are the performance constraints on the logging infrastructure?
Clearly, any logging activity that occurs in performance-critical
sections of the code need to be closely looked at... Do we have a
strategy for evaluating this for any proposed solution?

2. Are there any reliability/write guarantees on logging, in other
words, when some of the logging is sent to disk, is there any
requirement that it must arrive there before continuing, or is it not an
issue?

Kim

On Tue, 2007-05-08 at 18:19 -0400, Alan Conway wrote:
> I haven't found a logging solution that blows me away, rlog looks like
> the easiest for me to integrate. I propose to integrated it under a
> single-macro QPID_LOG API the following one-macro logging API which is
> type safe (ostream based), and should be efficiently implementable over
> any logging infrastructure that is capable of not evaluating the log
> message if no log will be generated.
> 
> rlog will let us retrieve logs by level, by component (arbirary
> collection of source files), by individual source file or combinations
> thereof. It has stderr and syslog backends built in and can be extended.
> It can be configured to include source file/line, thread ID, function
> name in logs. If it lets us down long term, we should be able to replace
> easily since only QPID_LOG macros will be widely distributed.
> 
> (rlog actually offers hierarchical channels beyond simple log levels,
> deliberately ignored to increase portability to future log
> infrastructures.)
> 
> Comments welcome but I'm implementing right away so speak up!
> 
> Cheers,
> Alan.
> 
> 


Mime
View raw message