[logback-user] TurboFilter scope

Don Griffin dgriffin at motorola.com
Mon May 19 15:53:53 CEST 2008


Hi Ceki,

Thanks for the reply.

On the hierarchy walking part, you are correct about costs. Of course, 
one could flatten and cache the result. Since changes in Logger behavior 
on-the-fly are rare (in comparison to log statements), one could store 
the flattened  TurboFilter[] on a Logger and invalidate it (set to null) 
for all children in the event of a change on a parent. For simplicity, 
this could be done with an AtomicReference to avoid undesirable lock 
hierarchies.

Of course, using AtomicReference and TurboFilter[] (as opposed to a 
Collection), the hierarchy walking may not be too terrible. Oh well, I 
am sure you know what they say about premature optimization. ;)

Just thoughts from one who is completely unfamiliar/ignorant of how the 
internals work. I'm sure you'll have much better insight on how such a 
feature might be implemented.

In my particular use case, I'm working in a server environment. We have 
several objects that we would like to use to adjust the logging in a 
TurboFilter kind of way (as opposed to an Appender). Say, per user or 
per group or maybe by some other property of our application objects.

We think we can force-fit the data we need in to the MDC. Someday I'll 
post a question/suggestion related to MDC, but for the sake of this 
thread, I'll save that one for another time. :)

Again, thanks!

Best,
Don

Ceki Gulcu wrote:
> Hello Don,
> 
> Thank you for the compliment abut logback.
> 
> Your proposal is quite interesting and has pros as well as cons.
> 
> On the pros side, it would indeed eliminate the need for evaluating
> TurboFilters for loggers which do not inherit any. Also, as you have
> stated, inherited filters allow for finer grained control. However,
> such flexibility comes at a cost. On the cons side, each logger would
> need to walk the hierarchy for determine the filters that would
> apply. Walking this hierarchy in a multi-threaded environment does not
> come totally free.
> 
> Thus, I would like to ask you whether you could describe your use-case
> in more detail. Could you describe your use-case please?
> 
> 
> Don Griffin wrote:
>> Firstly, as this is my first post, thanks for an overall great library!
>>
>> Having just read the section on TurboFilters, they are (almost) just 
>> what I need. I fear that the way they are implemented puts undue 
>> penalty and difficulty on their performance.
>>
>> I did scan the past several months in the archive and did not find any 
>> mention of TurboFilter, even still, this may be something someone else 
>> has already suggested. If so, I apologize for the noise. In any case, 
>> here is my suggestion:
>>
>> Why not put TurboFilters on Loggers instead of the global context? 
>> That is, the example from the (very helpful and well done) manual:
>>
>>   <configuration>
>>     <turboFilter class="chapter6.SampleTurboFilter">
>>       <Marker>sample</Marker>
>>     </turboFilter>
>>
>>     <appender name="STDOUT" class="...">
>>       ... snip ...
>>     </appender>
>>
>>     <root>
>>       <appender-ref ref="STDOUT" />
>>     </root>
>>   </configuration>
>>
>> Would change to:
>>
>>   <configuration>
>>     <appender name="STDOUT" class="...">
>>       ... snip ...
>>     </appender>
>>
>>     <root>
>>       <turboFilter class="chapter6.SampleTurboFilter">
>>         <Marker>sample</Marker>
>>       </turboFilter>
>>       <appender-ref ref="STDOUT" />
>>     </root>
>>   </configuration>
>>
>> Almost the same, and it would achieve the same result as the original. 
>> In my case, however, I could apply a TurboFilter to only the loggers 
>> that need it:
>>
>>   <configuration>
>>     <appender name="STDOUT" class="...">
>>       ... snip ...
>>     </appender>
>>
>>     <root>
>>       <appender-ref ref="STDOUT" />
>>     </root>
>>
>>     <logger name="foo">
>>       <turboFilter class="chapter6.SampleTurboFilter">
>>         <Marker>sample</Marker>
>>       </turboFilter>
>>     </logger>
>>
>>     <logger name="foo.bar">
>>     </logger>
>>   </configuration>
>>
>> In this case, the "foo.bar" logger would inherit the TurboFilter from 
>> the "foo" logger. In essence, each Logger object would have its own 
>> collection of TurboFilter objects that are the concatenation of any 
>> filters configured on itself, followed by its parent, grand-parent, 
>> etc. on up to the root of hierarchy.
>>
>> This approach should greatly reduce the total penalty for using such a 
>> powerful mechanism and at the same time give finer grained control 
>> over which filters apply to which loggers.
>>
>> Any thoughts?
>>
>> Best regards,
>> Don
>>
>>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user
> 



More information about the Logback-user mailing list