Re: [boost] [log] Boost.Log formal review ongoing

Subject: Re: [boost] [log] Boost.Log formal review ongoing
From: Darryl Green (darryl.green_at_[hidden])
Date: 2010-03-13 23:20:08

On Sat, 2010-03-13 at 22:14 +0300, Andrey Semashev wrote:
> On 03/12/2010 05:05 PM, Darryl Green wrote:
> >
> > Anyway - I've looked at the docs for boost.log and read some review
> > comments to see if we could replace this with the proposed boost.log.
> > I've reached the following (possibly wrong) conclusions:
> >
> > 1) there isn't a direct mapping from this style of logging
> 
> Except the filtering based on the message text, I'd say your case is 
> covered by Boost.Log rather well.
>  Some things, like having a source per 
> severity level, are not required with Boost.Log.
> 
Agreed. I should not have separated this from item 2 below.

> > 2) the obvious approach of making each element of the channel identifier
> > an attribute would seem ok - but I'm concerned that the cost of
> > evaluating the filters would be significant
> 
> The cost will be more significant than comparing a pointer against NULL, 
> that's for sure.
> 

That is my major concern. In a server app with detailed logging/tracing
available and many sessions generating messages the ratio of "disabled"
"channels" to enabled ones can be very large, making the performance of
the former very significant.

However, I can't see a way to directly incorporate this sort of
performance with the other desirable features of your library.
Attempting to represent this scheme as some sort of specialised
attribute (value) and filter still incurs a level of overhead in the
attribute lookup and filter expression processing that is undesirable.

Extending your lib by make our existing channel based log type into a
logger feature and implementing open_record such that it applies the
quick channel based filter first and returns a null record if the
channel/logger is disabled would seem to be the best approach. It would
also be desirable to use the set of sinks for which the channel filter
passed to short circuit the core filtering by adding the set of sinks
"attached" to the channel as an attribute of the message.

Does that sound workable?  

> > 4) it isn't immediately clear how to support dynamic configuration of
> > "filtering" and sinks
> 
> Well, the library allows to add/remove sinks, filters and formatters 
> during the run time. You can simply call the interface methods as you 
> would do it on the library configuration stage.
> 

Ok.

> > 5) attributes seem a little overloaded - the attribute as something to
> > be filtered on and the attribute as something to be included in
> > (formatted in to) the logged message roles are potentially different. It
> > would be nice to have expensive to evaluate attributes that played no
> > role in filtering but that were (after filtering "passed" the message)
> > evaluated conditionally based on filtering.
> 
> It looks to me that it's already implemented, but not exposed to the 
> user (since it's only an optimization). If an attribute is not used 
> during filtering, and the filter rejects the record, the attribute is 
> not evaluated at all.
> 

Good.

> > 6) There are use cases that boost.log can support (ones where the
> > filtering is based on more "dynamic" attributes) that are not practical
> > to support in the pure channel based model afaiks. I'd class most of
> > these as "alarms" where there is some sort of thresholding or similar
> > criteria applied to an attribute value (or combinations) to determine
> > whether to log the message.
> 
> Hmm, not sure I understand what you mean here. Severity levels, perhaps? 
> But you do use them, although they are a part of the channel name in 
> your case.

I mean that your library makes it possible to write a filter that logs
only if eg. packet_length is over 4K (assuming packet_length is an
attribute) which is not possible using the early/cached evaluation
implicit in the pure channel based approach. Using channel based
filtering it is necessary to classify "packet_length > 4096" into some
channel (maybe  "comms.messages.warning" or similar, externally to the
logging system, with less flexibility/configurability than boost.logging
offers. This is one reason I'd like to be able to combine both
approaches.

regards
Darryl.