[logback-user] TurboFilter scope

[Don Griffin]

Hi Ceki,

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 
filter implementation.

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).

Best regards,
Don