Anthony Maire created LOG4J2-1441:
-------------------------------------
Summary: Asynchronous logging + immediateFlush=false appenders :
potential data retention on end of batch event
Key: LOG4J2-1441
URL: https://issues.apache.org/jira/browse/LOG4J2-1441
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.6
Reporter: Anthony Maire
When using asynchronous logging, suggestion is made to use immediateFlush=false
for file-based appenders and rely on the end of batch detection to perform the
flush, which is supposed to happen in a timely manner
As per AsyncLogger JavaDoc
{quote}
For best performance, use AsyncLogger with the RandomAccessFileAppender or
RollingRandomAccessFileAppender, with immediateFlush=false
{quote}
As per File/RandomAccessFile appenders doc on the site
{quote}
Flushing after every write is only useful when using this appender with
synchronous loggers. Asynchronous loggers and appenders will automatically
flush at the end of a batch of events, even if immediateFlush is set to false.
This also guarantees the data is written to disk but is more efficient.
{quote}
However if there are multiple appenders for the same asynchronous mechanism
(either multiple appenderRef for an AsyncAppender or multiple AsyncLoggers
since they share the same disruptor instance), the last event of the batch will
only flush the appenders that are actually logging it, and data on other
appenders won't be flushed.
I made a small example using 2 asynchronous loggers, same kind of issue should
occur with several appenders linked to the same AsyncAppender when the last
event is filtered out because of it's level or a custom filter.
- 10 second after the start, all events are processed but the main thread will
not exit because of an infinite loop
- 2 events where processed by root logger and correctly logged in the console
appender
- only one event has been flushed to the file (the file appender is attached to
root logger too)
- I made a heap dump on the JVM, it shows that the RandomAccessFileManager
internal byte buffer has pending data ( byteBuffer.position=61)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]