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.froe...@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.po...@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.froe...@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-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org >
