I see. I was under the impression that the Filter checked
by Logger.isEnabled() was a composite of the global filters and the Logger
filter, but I just assumed and never really checked. Thanks for correcting
me.

Yes, I agree this is a good idea for a future enhancement.

I don't know how often people configure filters on AppenderRef though.
Depending on how expensive it is to check AppenderRef filters it may make
most sense to just check the LoggerConfig filters before enqueuing the log
event.

Remko

On Wednesday, 18 May 2016, Ralph Goers <ralph.go...@dslextreme.com> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','_...@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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> and a preview of the updated performance page is here:
>>>> 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
>>>> <javascript:_e(%7B%7D,'cvml','mechanical-sympathy%2bunsubscr...@googlegroups.com');>
>>>> .
>>>> For more options, visit 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
>>> <javascript:_e(%7B%7D,'cvml','mechanical-sympathy%2bunsubscr...@googlegroups.com');>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
>
>

Reply via email to