In the case of a multi threaded application, not async, would it be possible to have avoid the potential mis ordering by having a 500ms (for example) window of collection for log events, and instead of logging the next log event in the queue, the logic would be search for the oldest event in the queue and log it. I haven't looked for where that happens in the code so maybe this is not applicable or the performance impact would be too high.
On Thu, Dec 14, 2017 at 3:52 PM, Remko Popma <remko.po...@gmail.com> wrote: > Best to upgrade to 2.10 if you’re not on it yet. > > Cheers! > > (Shameless plug) Every java main() method deserves http://picocli.info > > > On Dec 15, 2017, at 8:45, Benjamin Jaton <benjamin.ja...@gmail.com> > wrote: > > > > Oh interesting. Well this one appender is not async but it is multi > > threaded, so I think that explains it. > > Useful to know about 2031 though. > > > > Thanks > > Benjamin > > > >> On Thu, Dec 14, 2017 at 2:54 PM, Remko Popma <remko.po...@gmail.com> > wrote: > >> > >> Are you using Log4j 2.10? > >> The reason I’m asking is that the 2.10 release contains a fix for > >> https://issues.apache.org/jira/browse/LOG4J2-2031. > >> > >> Prior to 2.10, there was a possibility that log events ended up out of > >> order in the log when you’re using async loggers or async appender and > the > >> appender could not keep up with the logging rate. Once the queue is > full, > >> previous versions of Log4j2 would bypass the queue and log directly to > the > >> appender. > >> > >> From 2.10, this only happens if Log4j2 determines there’s a risk for > >> deadlock, otherwise the thread will enqueue the log event (possibly > >> blocking until space is available in the queue). > >> > >> Remko > >> > >> (Shameless plug) Every java main() method deserves http://picocli.info > >> > >>> On Dec 15, 2017, at 7:22, Ralph Goers <ralph.go...@dslextreme.com> > >> wrote: > >>> > >>> In a multi-threaded application it is entirely possible that log > entries > >> might be appear to be out of order. This is because the LogEvent will > >> populate the timestamp field but then another thread might get control, > >> generate its log event, and then pass it to the appender before the > first > >> thread got a chance to pass the event to the appender. Are you seeing > log > >> entries that are out of order in the same thread? That shouldn’t happen. > >>> > >>> Ralph > >>> > >>>> On Dec 14, 2017, at 3:09 PM, Benjamin Jaton <benjamin.ja...@gmail.com > > > >> wrote: > >>>> > >>>> Hello, > >>>> > >>>> I am seeing logs that are not in order in the log file, it this > expected > >>>> when using a RollingFile appender? > >>>> > >>>> "appenders" : { > >>>> "appender" : [ { > >>>> "type" : "RollingFile", > >>>> "name" : "ServerAppender", > >>>> "PatternLayout" : { > >>>> "pattern" : "%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p %c{1}:%L - %m%n" > >>>> }, > >>>> "fileName" : "server.log", > >>>> "filePattern" : "server-%d{yyyy-MM-dd_HH-mm-ss}.log.zip", > >>>> "SizeBasedTriggeringPolicy" : { > >>>> "size" : "100MB" > >>>> }, > >>>> "bufferedIO" : "true", > >>>> "bufferSize" : "8192", > >>>> "immediateFlush" : "true", > >>>> "DefaultRolloverStrategy" : (...) > >>>> } > >>>> > >>>> Thanks > >>>> Benjamin > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
