There are a couple of open issues with the log4j AsyncAppender,
specifically:
http://issues.apache.org/bugzilla/show_bug.cgi?id=26224
http://issues.apache.org/bugzilla/show_bug.cgi?id=28006
http://issues.apache.org/bugzilla/show_bug.cgi?id=38137
I've reviewed the bug reports and the code in question and the issues
do appear to be legitimate. There appear to be two weaknesses in the
implementation: one if that the same object (bf) is used to notify
waiting threads that the queue can accept events and to notify that
the queue has events to process. Since notify() is used, the
notification intended to resume the dispatcher could wake up a thread
that was waiting since the queue was full.
There also appears to be a possibility where the appending thread and
the dispatcher could deadlock while synchronizing on bf.
I'm going to try to fabricate unit tests that will reproduce the
observed and anticipated problems. After that, I'm strongly tempted
to separate use distinct synchronization objects for queue accepting
and queue not empty notifications. In log4j 1.3, I'm also strongly
tempted to eliminate use of BoundedFIFO (while leaving it in the jar
for compatibility) and migrate to use of java.util.LinkedList. I'm
going to explore in log4j 1.3, but I'd expect that some fixes will
need to go back into the 1.2 branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
