log4j can evaluate many threshold checks (that is, is the level high
enough that this should be logged) concurrently, but its current
design can only process one logging request at a time once it passes
the threshold test. Eliminating that aspect of the design is the
major design goal for a proposed log4j 2.0. So regardless of what
appender configuration you have you will always see all but one
thread blocking for the duration of the append.
The reason that you would use an AsyncAppender is to reduce the
amount of the lock from the time it takes to actually write to a file
to the time it takes to add the the event to a queue. If you are
flooding the AsyncAppender by sending it messages more rapidly than
it is able to write using the underlying appender and you have not
specified blocking=false (introduced in log4j 1.2.14 also in the SVN
trunk for 1.3), then you will degrade to the same performance. If
you specify blocking=false on the AsyncAppender, if you do flood the
appender, then the overflow messages will be counted and summarized,
but will not block waiting for the underlying appender. I would
recommend that you upgrade to log4j 1. 2.14 if you use AsyncAppender
in any mode since the previous one had several reported problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
