[ 
https://issues.apache.org/jira/browse/LOG4J2-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161643#comment-16161643
 ] 

Colin McDowell commented on LOG4J2-2031:
----------------------------------------


I looked up the Log4j2 documentation.  Appears to have a different description 
of AsyncQueueFullPolicy.

https://logging.apache.org/log4j/2.x/manual/configuration.html#log4j2.AsyncQueueFullPolicy

Was there supposed to be a change in v2.9.0?  Testing that version didn't show 
any difference in ordering issue.

> 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)

Reply via email to