[logback-dev] [JIRA] Updated: (LBCLASSIC-53) Add MDC Level Filtering

[Ceki Gulcu]

Ralph Goers wrote:

[snip]

> Next your description doesn't seem to describe how the filter actually 
> works. I'm somewhat confused as well because in one paragraph you said 
> "can easily accommodate case 2" and then in the next paragraph "the 
> second case cannot be accommodated".

Ooops:

What I meant to say was:

I can think of two major use cases.

Case 1) The logging system is mostly silent but we would like to
increase verbosity for users Alice and Bob and keep it as is for the
other users.

Case 2) The logging system is mostly verbose but we would like to
decrease verbosity for certain requests, say typeA and typeB, and keep
it as is for the other types of requests. Here I assume that the type
of request is can be easily and accurately set on the MDC.

Now, DynamicThresholdFilter, as a threshold, can easily accommodate
case 2. Set the threshold high (e.g. ERROR) for typeA and TypeB, and
set the root level to a low level such as DEBUG or INFO. You are done.

The *first* case cannot be accommodated with the current
implementation of DynamicThresholdFilter because it returns NEUTRAL
when the request level is higher or equal to the threshold level
(computed dynamically from MDC). We would want to return ACCEPT
instead. Do you see why?

I also note that the defaultThresold value is not useful in any of the
above use cases.

> I have to look at the code again but I'm pretty sure it should work 
> differently than what you describe. It should accomodate both use case 1 
> and 2.

> Assume that the default level is set to Warn. Messages destined for user 
> carol would be rejected by this filter (i.e. return DENY) unless they 
> are Warn or Error messages. On the other hand, if users Alice and Bob 
> are set to Debug then messages that match them will pass through the 
> filter unless they are trace messages. However, we don't want to accept 
> these just yet as the intention is not to log everything for these 
> users, only to allow the rest of normal filtering to occur. To do that 
> the filter must return NEUTRAL. This allows use case 1 to work correctly.

I see. So in this case the default level is quite crucial. Your point about 
letting normal processing to occur also makes sense. However, it must be assumed 
  that normal processing lets messages through, if root level set to error, having
DynamicThresholdFilter return NEURAL does not help. Of course, if normal 
processing lets messages go through, then the current impl of 
DynamicThresholdFilter fits the bill nicely.

> Now, if the default level was Trace all messages would pass through the 
> filter. However, if Alice and Bob are now set to Error messages related 
> to them would not pass through the filter unless they were only Errors. 
> This should satisfy use case 2.  

Yes, indeed.

In LevelFilter [1], there is a possibility of returning ACCEPT, DENY or NEUTRAL 
either onMatch or onMisMatch. This allows for 6 onMatch/onMismatch combinations.
In the current impl, we only use 1 out of the 6. If common use cases can be 
covered by just 1 combination, that's fine with me. :-)

[1] http://logback.qos.ch/apidocs/ch/qos/logback/classic/filter/LevelFilter.html

-- 
Ceki Gülcü

QOS.ch is looking to hire talented developers located in Switzerland
to work on cutting-edge software projects. If you think you are
qualified, then please contact ceki at qos.ch.