Mailing-List: contact qpid-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: qpid-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of
 martin.a.ritchie@googlemail.com designates 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=p7nC8t14YRa9lfKS06oXG9gvN5ScMTkEOT+nCSpQHHK5tD0q8pNruNtqvgXsVETueIdVFD4w6iGiS1i9ro4aaiUiFqnLiFGg5sWLYII1Ls3h8rvScpYheC6uuUW9l43NFO3XCwBjuoyU/I63jKKJZJTx2eNlldqDxsPatHwBAmE=
Message-ID: <99e30fe50705090803w298d4af7pb9f945c96f1017b9@mail.gmail.com>
Date: Wed, 9 May 2007 16:03:36 +0100
From: "Martin Ritchie" <ritchiem@apache.org>
Sender: martin.a.ritchie@googlemail.com
To: qpid-dev@incubator.apache.org
Subject: Re: Proposed qpid logging API
In-Reply-To: <1178717256.24526.55.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1178662780.24526.18.camel@localhost.localdomain>
	 <1178711631.5131.21.camel@busy-beaver.boston.redhat.com>
	 <1178717256.24526.55.camel@localhost.localdomain>

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.

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.
>
>


-- 
Martin Ritchie