[logback-user] Buffered Appender?

Eric Faden eric at techeminence.com
Mon Aug 18 04:35:08 CEST 2008


I think you are correct, doing it at the filter level seems awkward and 
more complex than it needs to be.  I think that the appender method is 
going to work out the best.  Thanks for the advice and the info.


Ceki Gulcu wrote:
> 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

More information about the Logback-user mailing list