[logback-user] Buffered Appender?

Ceki Gulcu listid at qos.ch
Sat Aug 16 18:40:42 CEST 2008


Hello Eric,

You could place the logic in a TurboFilter. TurboFilters are set at the 
LoggerContext (i.e. global) level and they intervene before all other components 
in the processing pipeline.

If my memory serves me correctly, creating a LoggingEvent takes about 200 
nanoseconds which is pretty fast. However, for a disabled logging event logback 
can reach a decision (not to log) in about 10 nanoseconds.

But since you wish to buffer the logging events, they must be created. You can't 
buffer what does not exist. Moreover, TurboFilters are not supposed to buffer 
events. They could, but it's not a use case we've considered nor currently support.

The current architecture is linear at the beginning and branches out at the 
level of appenders. In ASCII art, this looks like

                                   /-->ap0-->F00-->F01->F0n
                                  /-->ap1-->F10-->...
TB0->TB1->...->TBm->LLFilter->--|-->ap2-->F20->...
                                  \-->ap...
                                   \-->apX->FX0->...

What you are suggesting resembbles

        /-->apJ-->...     /....
       /-->apJ+1-->..    /
      /-->apJ+...-->    /
     /-->apJ+j-->      /
TB0--------------->TB1-->....-->LLFilter-->....unchanged

Where
TB stands for TurboFilter
LLFilter stands for Logger Level filter which is the main filter in logback
ap stands for appender

As I understand it, the advantage of "sectional logging," as we have been 
discussing, is to be silent if things go well, unless an error occurs, in which 
case we dump detailed logging information. Is this how you see things or am 
entirely I missing the point?

Doing sectional logging at the appender level would be the simplest way to 
proceed. You could do it at other points in the processing pipeline but you'd 
need to code a lot more on your own and frankly I don't see what you would gain. 
However, I might be wrong.

Eric Faden wrote:
> Cool thanks.  I got the idea then.  Is there any way to do something 
> like that in the filter level or before it got to the appender?  Also 
> how inefficient would it be to create the LoggingEvent?  My idea would 
> be to only put this appender on certain classes if for instance there is 
> an exception we are trying to track down.  It seems that based on the 
> code creating the LoggingEvent isn't very expensive since the string 
> isn't built until it is actually appended.  So setting the Debug level 
> higher and having the Appender handle it wouldn't incur that much of a 
> performance penalty.  Right?
> 
> -Eric

-- 
Ceki Gülcü

QOS.ch is looking to hire talented developers located in
Switzerland. Please contact ceki at qos.ch for details.


More information about the Logback-user mailing list