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
