On Oct 30, 2007, at 3:01 PM, Simon Park wrote:
Hi,
I've posted code (Apache license, Log4J coding standards) that I
hope will offer an alternative to the standard Log4J
AsyncAppender. The design intention is to facilitate reduced
blocking for logging operations, thereby allowing higher throughput
for heavily-threaded applications. More at http://
simonsiteblog.blogspot.com/2007/10/ive-been-working-on-alternative-
to.html.
Is this useful? I would welcome feedback.
Simon
Haven't looked at the code, but I see your point. The log4j 1.2.14
and later AsyncAppender does delay blocking relative to the prior
AsyncAppender (and can skip blocking all together is blocking=false),
but when it does block, it will block longer. The GC pause metaphor
is pretty right on the mark.
The earlier AsyncAppender did pull an event at a time off the buffer,
but I found that difficult to do the non-blocking option with that
approach. However, you could likely modify the loop at the end of
Dispatcher.run to pull one event off the queue for each completed
append when the appender is blocking=true and the appenders buffer is
already full and blocking.
AsyncAppender.close() will joins with the dispatcher thread,
essentially blocking until all pending log requests are handled. So
I don't think the more reliable logging at end of application is an
issue. Obviously, any abnormal termination may result in lost
logging requests, but that will be proportional to the buffer size.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
