[
https://issues.apache.org/jira/browse/LOG4J2-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16173217#comment-16173217
]
Remko Popma edited comment on LOG4J2-2031 at 9/20/17 3:46 PM:
--------------------------------------------------------------
Fixed in master.
Please verify and close.
----
With this change, you should no longer see out-of-order messages in the log
file.
When the async queue is full, Log4j2 will now by default block until a slot
becomes available in the queue (unless recursive logging is detected).
This will impact your performance test mentioned in the description of this
ticket. I would suggest increasing the queue size to match the number of
messages logged in the test, if you want to test async logging speed. With a
smaller queue you are essentially measuring the speed of the underlying
appender.
If you want to discuss performance testing further, please raise a separate
ticket or we can discuss on the log4j-user mailing list.
was (Author: [email protected]):
Fixed in master.
Please verify and close.
> 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, 2.9.1
> Environment: Windows, Sun Java 8.
> Reporter: Colin McDowell
> Assignee: Remko Popma
> Fix For: 2.10.0
>
> 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)
