qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Proposed qpid logging API
Date Wed, 09 May 2007 17:54:55 GMT
On Wed, 2007-05-09 at 16:03 +0100, Martin Ritchie wrote:
> Just a shame we can't use the same in the Java Broker, would have been
> good to have shared configuration files so we could get similar
> logging from both brokers with a single configuration.
> 
Agreed and not ruled out. My goal today is to establish an API for log
statements that can easily be re-implemented over other frameworks,
establish one low-impact-if-off implementation and get the code somewhat
instrumented so I can move on with other things. 

I think rlog is the fastest way to get there today but I don't think
it'll be the last or best logging option we'll support. In fact I will
provide a second non-rlog implementation to satisfy Apache's LGPL
phobia, so logging impl will be a real build-time option. I don't expect
alternate logging impls to have the same configuration - only that they
are source-compatible with the QPID_LOG macro so the impact of change is
local.

The amount of code I'm actually writing is *very* small, so I wont cry a
bit if someone wants to replace it with log4c?? or whatever in the
future. I do expect we'll settle on one "best" logging implementation at
some point not too far away but I gave up on this being it.

Cheers,
Alan.

> On 09/05/07, Alan Conway <aconway@redhat.com> wrote:
> > On Wed, 2007-05-09 at 07:53 -0400, Kim van der Riet wrote:
> > > Two silly questions:
> > Quite pertinent actually!
> >
> > > 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?
> >
> > My main criteria for now is near-zero overhead for disabled log
> > statements so we can reasonably leave logging in production code. rlog
> > is the best of the bunch in that regard, and probably at the theoretical
> > limit short of actually compiling them out: a single if (ptr!=0) (with
> > extra optimization hints for g++) - ends up about 3 machine instructions
> > on x86 for disabled logs.
> >
> > The other dimension is performance when logging is enabled, which
> > determines how much logging you can usefully turn on before things slow
> > to the point of uselessness. Pantheios is the winner here:
> > http://pantheios.sourceforge.net/performance.html but as the graphs show
> > the differences with logging enabled are not nearly as dramatic as the
> > logging off differences. The proposed QPID API will perform like the
> > IOStream column in those tests. The native rlog printf API would be
> > about the same (like logprintf in the graph).
> >
> > Rationale for the API:
> >  - Macro API is most flexible and easiest to wrap around other APIs.
> >  - Ostream formatting is type safe
> >  - Most "stringable" C++ types have ostream<< operators
> >  - boost::format provides printf formatting compatible with ostream.
> >
> > Rationale for rlog:
> >  - fastest in no-logging case
> >  - small but flexible and covers basics
> >  - I estimate will be quickest for me to implement in Qpid.
> >
> > Rlog is not "the" qpid logging framework, its just the first impl. I'll
> > do a brain-dead homegrown alternative to satisfy Apache licensing. We
> > can replace with another alterantive if/when we feel the need.
> >
> > > 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?
> >
> > Assume there are no guarantees at all. Logging (in this sense of the
> > overloaded word) is for debug/management purposes. It's best effort but
> > it should not take measures to be reliable that would slow the app down.
> >
> > Actual guarantees depend on how back-end is implemented, which I think
> > is regular buffered file writes or syslog calls depending on how you
> > configure.
> >
> > Cheers,
> > Alan.
> >
> >
> 
> 


Mime
View raw message