[logback-user] TurboFilter scope

Ceki Gulcu listid at qos.ch
Tue May 20 10:58:47 CEST 2008

Comments inline.

Don Griffin wrote:
 > On the hierarchy walking part, you are correct about costs. Of course,
 > one  could flatten  and  cache  the result.  Since  changes in  Logger
 > behavior on-the-fly  are rare (in  comparison to log  statements), one
 > could store the flattened TurboFilter[]  on a Logger and invalidate it
 > (set  to  null) for  all  children  in the  event  of  a  change on  a
 > parent. For simplicity, this could  be done with an AtomicReference to
 > avoid undesirable lock hierarchies.

I am not familiar with AtomicReferences. They sound like "fun".

 > Of course, using AtomicReference and TurboFilter[] (as opposed to a
 > Collection), the hierarchy walking may not be too terrible. Oh well, I
 > am sure you know what they say about premature optimization.

Yes, premature optimization is the root of all long discussions.

 > Just thoughts from one who is completely unfamiliar/ignorant of how
 > the internals work. I'm sure you'll have much better insight on how
 > such a feature might be implemented.

Well, maybe, but your analysis above was pretty good.

 > In my particular use case, I'm working in a server environment. We
 > have several objects that we would like to use to adjust the logging
 > in a TurboFilter kind of way (as opposed to an Appender). Say, per
 > user or per group or maybe by some other property of our application
 > objects.

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?

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?

 > We think we can force-fit the data we need in to the MDC. Someday I'll
 > post a question/suggestion related to MDC, but for the sake of this
 > thread, I'll save that one for another time. :)

As you wish.

 > Again, thanks!

My pleasure.

More information about the Logback-user mailing list