Log4J Asynchronous Appender

I've been working on an alternative to the Log4J AsyncAppender. OK, but why bother when the standard Log4J AsyncAppender works well enough? In a heavily-threaded application the AsyncAppender can block when its buffer is full, and the dispatcher thread is still busy appending LoggingEvents. This is because AsyncAppender grabs all LoggingEvents from its buffer, and appends all those LoggingEvents in a single loop before checking the buffer contents again. Such blocking is analagous to a GC pause.

In trying to minimise such pauses whilst maximising throughput, I've come up with a slightly different solution to the same problem that AsyncAppender tries to address. The ActiveAsynchronousAppender I have developed blocks when the buffer is full, however it only appends a single LoggingEvent from its buffer at a time, before checking the buffer again. As soon as the buffer is below its maximum size, the appender ceases to block.

I've run the new code against the Log4J 1.2.15 unit tests for the AsyncAppender, and the important tests pass. The caveat is that my code is not designed for "non-blocking" operation, i.e. it cannot be configured to discard LoggingEvents when the appender's buffer is full.

What are the benefits of the new code? As with the standard Log4J AsyncAppender, it depends in no small part upon the nature of the application, and tuning the size of the appender's buffer. I don't yet have any hard figures to demonstrate whether my appender code offers any significant advantage over the existing Log4J AsyncAppender. A couple of things I'm looking at:

• Reduced blocking should lead to higher application throughput
• Fewer LoggingEvents on the stack of a daemon thread may mean more reliable logging at the end of an application lifecycle (not sure about this)