TurboFilters to transform events
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
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@qos.ch http://qos.ch/mailman/listinfo/logback-dev
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
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@qos.ch http://qos.ch/mailman/listinfo/logback-dev
On 18/03/2010 8:53 PM, Ralph Goers wrote:
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.
Thank for sharing this information. Writing a logging framework from scratch is no easy task but since you are an excellent developer I'm sure you'll manage to come up with something innovative. -- Ceki
participants (2)
-
Ceki Gülcü -
Ralph Goers