That is only checking the global filters. Filters can also be on the Logger (or more accurately, the LoggerConfig), AppenderRef, or Appender. I don’t think it would ever work to check the filters on the appenders, but I would think it would be possible to check those on the Logger and possibly even the AppenderRef, although checking the AppenderRef could get very complicated.
Ralph > On May 17, 2016, at 6:37 PM, Remko Popma <remko.po...@gmail.com> wrote: > > Ralph, > > I don't think so: AbstractLogger calls logIfEnabled() which calls isEnabled() > before calling logMessage(). > > So, even with AsyncLogger the Filters on the Logger are checked before the > event is created or enqueued. > > I don't see an issue with the current code. > > Remko > > Sent from my iPhone > > On 2016/05/18, at 6:33, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > >> Remko, >> >> Benedict makes a good point. While I don’t think filters on appenders should >> be called before putting events on the queue we should probably be executing >> the filters on the Logger. But currently those are called in the >> LoggerConfig, which I think is after the events are added to the queue. >> >> Ralph >> >>> On May 17, 2016, at 12:55 PM, Benedict Elliott Smith <bened...@apache.org >>> <mailto:bened...@apache.org>> wrote: >>> >>> Could I suggest that you run tests for latency and throughput effects of >>> using this in systems with only moderate-to-low numbers of logging calls? >>> (i.e. the vast majority of systems!) >>> >>> It's very likely that in such systems messages will not reach a velocity to >>> keep the Dispatcher running, and so logging calls may often (or always) >>> involve a Futex call - which is not a trivial cost. There will almost >>> certainly be systems out there with anti-ideal characteristics - logging >>> just often enough that these costs materially impact throughput, but not >>> often enough that they suddenly disappear. >>> >>> Even though a majority of systems do not need this, because it "async" and >>> the new hotness, and there are no advertised downsides, everyone will try >>> to use it. It's up to those who know better to make sure these people are >>> informed it isn't a free lunch. Making sure all of the caveats are >>> reported on the advertising page would be a great start IMO. >>> >>> Might I also separately suggest you consider filtering events prior to >>> placing them on the queue for processing by the dispatcher? I've only >>> briefly glanced at the code, but it seems not to be the case currently. >>> >>> >>> On 17 May 2016 at 18:50, Benedict Elliott Smith <_...@belliottsmith.com >>> <mailto:_...@belliottsmith.com>> wrote: >>> Could I suggest that you run tests for latency and throughput effects of >>> using this in systems with only moderate-to-low numbers of logging calls? >>> (i.e. the vast majority of systems!) >>> >>> It's very likely that in such systems messages will not reach a velocity to >>> keep the Dispatcher running, and so logging calls may often (or always) >>> involve a Futex call - which is not a trivial cost. There will almost >>> certainly be systems out there with anti-ideal characteristics - logging >>> just often enough that these costs materially impact throughput, but not >>> often enough that they suddenly disappear. >>> >>> Even though a majority of systems do not need this, because it "async" and >>> the new hotness, and there are no advertised downsides, everyone will try >>> to use it. It's up to those who know better to make sure these people are >>> informed it isn't a free lunch. Making sure all of the caveats are >>> reported on the advertising page would be a great start IMO. >>> >>> Might I also separately suggest you consider filtering events prior to >>> placing them on the queue for processing by the dispatcher? I've only >>> briefly glanced at the code, but it seems not to be the case currently. >>> >>> On 17 May 2016 at 18:33, Martin Thompson <mjpt...@gmail.com >>> <mailto:mjpt...@gmail.com>> wrote: >>> Hi Remko, >>> >>> I'd just like to say that it is a great service to the community as a whole >>> that someone is seriously looking at improving logging. >>> >>> If you keep it up you'll be putting folks like me out of a job :) >>> >>> Martin... >>> >>> >>> On 17 May 2016 at 18:13, Remko Popma <remko.po...@gmail.com >>> <mailto:remko.po...@gmail.com>> wrote: >>> Hi all, >>> >>> First, my thanks to the many people who gave helpful advice and feedback on >>> how to measure Log4j response time on this list some time ago. >>> >>> We're about to start the Log4j 2.6 release. >>> If anyone is interested, a preview of the garbage-free logging manual page >>> is here: http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html >>> <http://home.apache.org/~rpopma/log4j/2.6/manual/garbagefree.html> >>> and a preview of the updated performance page is here: >>> http://home.apache.org/~rpopma/log4j/2.6/performance.html >>> <http://home.apache.org/~rpopma/log4j/2.6/performance.html> >>> >>> Feedback welcome! >>> >>> Remko >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "mechanical-sympathy" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to mechanical-sympathy+unsubscr...@googlegroups.com >>> <mailto:mechanical-sympathy+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "mechanical-sympathy" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to mechanical-sympathy+unsubscr...@googlegroups.com >>> <mailto:mechanical-sympathy+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >>> >>> >>
