[logback-user] TurboFilter scope

[Don Griffin]

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
>