I succeed to reproduce the issue I was suspecting to happen : https://issues.apache.org/jira/browse/LOG4J2-1441
2016-06-17 15:11 GMT+02:00 Anthony Maire <maire.anth...@gmail.com>: > Hello > > As suggested in AsyncLogger javadoc, I made some performance tests on my > application with (Rolling)RandomAccessFile appenders configured with > immediateFlush = false to take advantage of the potential I/O batching, and > the results are very good :) > > However I have a question about the flush on end of batch mechanism when > there are several appenders to flush. > > *Case one:* > > - AsyncLogger L1 has very few messages to log (let's say its a logger > which logs only when a request fails) and has its dedicated RAF appender A1. > - AsyncLogger L2 is very active (let's say its a logger which logs every > request that enters the system), and has its dedicated RAF appender A2 > > As far as I understand the code, both loggers use the same disruptor > instance. Let's assume that at some time, an event E1 is submitted to the > disruptor by L1, but the background thread doesn't wake up immediately and > another event E2 is submitted by L2, so both events will be part of the > same batch when the background thread wakes up > > I'm afraid that the following will happen : > - A1 encode E1 in its buffer, but does not write to the RAF since > event.isEndOfBatch() == false > - Background thread now process E2, it will be encoded in A2 buffer, and > since E2 is a end of batch event, A2 is flushed > However A1 is not flushed and will never be until another event is logged > to it. > > *Case Two:* > > Same kind of idea with a single AsyncLogger or AsyncAppender, 2 RAF > appender referenced on it, one of them as a filter (or a level that is > higher than the source level). If the end of batch event is filtered out > for an appender, is there a mecanism that will make flush earlier events > that were ine the same batch ? > > I try to find something in the code that will prevent this issue to > happen, but I didn't succeed to find one. Since reproducing these cases is > not trivial to test , I would like to have the analysis of someone who > knows the code better than I do :) > > Regards, > Anthony > > > > > >
