[logback-user] TurboFilter scope
dgriffin at motorola.com
Tue May 20 18:38:16 CEST 2008
Thanks again for the thoughtful reply.
Ceki Gulcu wrote:
> Ignoring performance considerations, i.e root of all long
> discussions, if you wish to filter per user or per group, does it also
> make sense to add per logger filtering on top of filters based on the
> user? Does your use case call for "user+logger"-based filters or just
> user-based filters?
I'm not sure I follow the "per logger filtering on top of" part. Are you
describing a logger-based appender filter that would follow an appender
filter for user (or other context)?
> If your use case calls for user-based filters, then is it accurate to
> say that your request for "user+logger"-filters is essentially
> motivated by improving filtering performance?
You are correct - the primary reason for the request is performance. The
secondary and tertiary reasons are simplification of configuration and
In typical use our sever will be handling high request volume. This is
what really attracted us to the TurboFilter concept. With it we can
avoid message building for all appenders by controlling the verbosity
primarily at the logger level. We tend to view all appenders as
equivalent, differing primarily by where/how the log data is stored. We
may occasionally want to select different messages for different
targets, but that is far down on our list of use cases.
In our system we are likely to have dozens of per-class loggers, fewer
per-package loggers and a handful of other "shared" loggers. What we are
wanting to accomplish with filters is to govern certain loggers based on
application-level context (such as "user", but other objects as well).
The logger in question may be a parent or perhaps package-level logger
that we want to tune to control logging for all components of the package.
Of course, we have several sub-systems that may have different criteria
governing their logging. This would most naturally be realized using
multiple filter instances. Since these are global, they must filter not
only based on the application-relevant context, but also on the logger.
We were concerned that having multiple such filters could easily become
a performance problem. Especially since (in our case) most filters do
not apply to most logger instances. The additional coding to include the
logger selection criteria and the resulting configuration data to manage
it were of some concern, but we didn't rank them very high (no system is
a perfect fit for everyone's environment).
More information about the Logback-user