logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: [External] Re: Log4j2 Async logger fallback method
Date Wed, 03 Jan 2018 08:42:57 GMT
No, the default async queue full policy is to block and not drop any events. (This is different
from Logback whose AsyncAppender is “lossy by default if 80% full”.) Log4j 2.10 will block
until space becomes available in the buffer. 

If you configure the DiscardingAsyncQueueFullPolicy (https://logging.apache.org/log4j/2.x/log4j-core/xref/org/apache/logging/log4j/core/async/DiscardingAsyncQueueFullPolicy.html),
events below the threshold are discarded when the queue is full. The default threshold is
INFO, so trace and debug events are discarded, while INFO and higher events will not be discarded
so the appender will have to block until space becomes available. 

I hope this clarifies things. :-)

Remko 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Jan 3, 2018, at 17:08, Fröstl, Christian <christian.froestl@accenture.com>
wrote:
> 
> Hi,
> 
> Thanks for your response.
> Just one question to verify.
> In the default configuration, all events of level info, debug and trace will be dropped,
if the ringbuffer is full. For all other events the application will block and if the ringbuffer
has space again, the block will release and the events will be written, right?
> That means that only events of type Info, debug and trace could be lost, but none of
the higher levels like error, warn and severe, right?
> 
> Kind regards,
> Christian
> 
> On 22.12.17, 01:53, "Remko Popma" <remko.popma@gmail.com> wrote:
> 
>    Yes by default the application thread will block until a slot becomes available in
the queue. 
> 
>    Yes this is configurable: see https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_logging-2Dlog4j2_blob_master_log4j-2Dcore_src_main_java_org_apache_logging_log4j_core_async_AsyncQueueFullPolicyFactory.java&d=DwIFaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=37nF0SnGtdjmcblOpYG7cKwaPDc1GWo5GNDvnDLF8TE&m=hk-mti7hK6agTdNqpiQVl3gpA4ri4hrn2pxHf_8maIE&s=QykinLq8RJFWq5YIigJq8wWizXFOxKy3DWeXTomCnaM&e=
> 
>    (Shameless plug) Every java main() method deserves https://urldefense.proofpoint.com/v2/url?u=http-3A__picocli.info&d=DwIFaQ&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=37nF0SnGtdjmcblOpYG7cKwaPDc1GWo5GNDvnDLF8TE&m=hk-mti7hK6agTdNqpiQVl3gpA4ri4hrn2pxHf_8maIE&s=w_w2x7qWvjFgf1pKLN7kb5Q534FwglDl16TI5-OArl4&e=
> 
>> On Dec 20, 2017, at 2:03, Fröstl, Christian <christian.froestl@accenture.com>
wrote:
>> 
>> Hi,
>> 
>> I currently don’t find any documentation regarding the fallback methods of the
log4j2 async logger.
>> What happens when the AsyncLogger.RingBufferSize is too small to log all entries
from a burst? Will the application fall back into sync logging and slow down the application
or will the new messages be dropped?
>> Is this a configurable behaviour?
>> 
>> Kind regards,
>> Christian
>> 
>> 
>> ________________________________
>> 
>> This message is for the designated recipient only and may contain privileged, proprietary,
or otherwise private information. If you have received it in error, please notify the sender
immediately and delete the original. Any other use of the email by you is prohibited.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
> 

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message