The following block: synchronized (this) { // // if a previous async task is still running //} if (lastRolloverAsyncAction != null) { // // block until complete // lastRolloverAsyncAction.close(); // // or don't block and return to rollover later // //if (!lastRolloverAsyncAction.isComplete()) return false; } from RolingFileAppender.java means that the next LoggingEvent which triggers a TriggerPolicy::isTriggeringEvent after the gzip compression has begun will cause all logging threads to block. The: if (lastRolloverAsyncAction != null) { check should not be performed until the NEXT rollover is called for. That is after: if (rollover != null) {
FYI: This is regarding o.a.l.rolling.RFA in the extras companion, Seems like it should be very rare for the stock rolling policies to return null for rollover(). Moving the block for completion of async tasks until after if (rollover != null) would seem to insignificantly delay the blocking, There is some commented out code indicating a developer considered failing the rollover instead of blocking. That would seem to be a more desirable approach. Maybe it could be configurable? Would appreciate knowing more about your situation and the benefit you saw from changing the location of the block.
We had accumulated a large log file approximately 10GB in size. Just using gzip on the (Linux) box in question required about 2 minutes to compress the file. The rollover check happens then next time a logging event comes in and the check interval has been exceeded which for our purposes meant essentially the next time the check interval was exceeded (1000ms I believe). All of our threads then blocked until the GZip operation was complete causing the system to stop responding for that interval. I didn't actually move the block in question, but the only time it makes sense to block on lastRolloverAsyncAction is when its value is about to change which will not be until the next log roll is required which was midnight in our application.