[logback-dev] TurboFilters to transform events

[Ralph Goers]

The only turbo filter I developed for Logback with the DynamicThresholdFilter. 

Actually, at this point I'm working on Log4j 2.0. The basic part is there, now I'm working on the XML configuration. I've used very little existing code to this point. FWIW, there are no logger hierarchies. That creates a problem that you have in Logback. When you reconfigure there is a window where all the logging configuration is screwed up. First you call reset() which clears everything and then the configuration happens component by component, all while the system is running. In my tests so far I am pretty close to the performance of Logback.

Ralph

On Mar 18, 2010, at 6:56 AM, Ceki Gülcü wrote:

> 
> Attaching filters to loggers is not so easy because it would require a
> logic for filter chaining. I think user would have difficulty
> understanding that logic. Moreover, filter chaining would involve
> walking up logger the hierarchy which would be much slower than what
> we have currently.
> 
> BTW, have you developed your own custom turbo filters?
> 
> 
> On 18/03/2010 2:17 PM, Ralph Goers wrote:
>> I think you should leave TurboFilters the way they are. However, you could allow filters to be attached to Loggers. Then the user could transform the event there.
>> 
>> Ralph
>> 
>> On Mar 18, 2010, at 3:56 AM, Ceki Gülcü wrote:
>> 
>>> Hello all,
>>> 
>>> At present time, a TurboFilter cannot modify the contents of an
>>> event. This decision was made in order to avoid the cost of
>>> constructing a LoggingEvent (about 20 nanoseconds) which would be
>>> later tossed out by the logger-level filter. 20 ns is not much but in
>>> absolute terms but considering that invoking the logger-level filter
>>> costs 3ns, 20ns is quite a steep price to pay in relative terms on
>>> every logger printing method invocation (for disabled logger
>>> requests).
>>> 
>>> For the case where there are no turbo filters installed, performance
>>> would remain quasi-identical. For the case with one or more turbo
>>> filters installed, there would be an extra cost of 20ns. However,
>>> since invoking even the most rudimentary turbo filter costs 40ns or
>>> more, I think the 20ns overhead is well spent considering that it
>>> would allow turbo filters to transform events.
>>> 
>>> Unfortunately, the TurboFilter interface would need to be modified
>>> breaking compatibility with existing turbo filters.
>>> 
>>> Comments?
>>> 
>>> --
>>> Ceki
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev