[
https://issues.apache.org/jira/browse/LOG4J2-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16162158#comment-16162158
]
Remko Popma commented on LOG4J2-2031:
-------------------------------------
Hi Colin,
The {{AsyncLoggerConfig.RingBufferSize}} property doesn't apply: it is for when
using [async loggers|https://logging.apache.org/log4j/2.x/manual/async.html]
(when the configuration contains {{AsyncLogger}} or {{AsyncRoot}} instead of
{{Logger}} and {{Root}}).
Your test configuration uses a different way to be async: {{AsyncAppender}}.
To control the queue size of this appender, specify attribute
{{bufferSize="8096"}} on the [Async appender element in the
configuration|https://logging.apache.org/log4j/2.x/manual/appenders.html#AsyncAppender].
FYI, async loggers have a default queue size of 128 * 1024 slots. The default
for AsyncAppender is tiny by comparison. Note to self: we should increase that.
Thanks for verifying that the out of order messages are indeed caused by the
AsyncQueueFullPolicy. Good point about external libraries. I agree that
configuring a custom policy that ENQUEUEs by default is not a realistic option.
I'm planning to do some work to fix this properly. (Some of my comments were
also to get feedback on that from the Log4j2 community.)
Until then, please use a large queue size that is able to absorb most bursts of
events.
> Messages appear out of order in log file (was: Log4j2 log file not reflecting
> application log function calls)
> -------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-2031
> URL: https://issues.apache.org/jira/browse/LOG4J2-2031
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.8.2, 2.9.0
> Environment: Windows, Sun Java 8.
> Reporter: Colin McDowell
> Assignee: Remko Popma
> Attachments: CapacityTest.java, log4j2.xml, pom2.xml
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Was hoping to move our numerous J2EE projects from Log4j to Log4j2 for the
> performance improvements. I put together a small test case that writes a
> string pattern to a Rolling File. There is a 6 digit sequence number at the
> start of the log message. This allows me to quickly see if all the log
> requests are making it into the log file. I attach the test case and
> log4j2.xml. The log4j2.xml uses an asynchronous appender.
> What I observe in the output log file is that after a short interval (120 or
> so entries) the logged are appearing in the wrong order, and entries can be
> missing. The missing entries issues especially shows up when rolling to the
> next log file.
> Perhaps there is a deliberate decision to not to guarantee log file
> accurately for speed. However we need the logs to accurately reflect what
> the application is logging. I have also noticed the performance is 25% worse
> in Log4j2 than Log4j when not using the asynchronous appender. So that
> rather kills us using Log4j2 at the moment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
