[jira] [Comment Edited] (LOG4J2-2031) Messages appear out of order in log file (was: Log4j2 log file not reflecting application log function calls)

["Remko Popma (JIRA)" <ji...@apache.org>]

    [ 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: remkop@yahoo.com):
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)