On Nov 3, 2009, at 6:13 AM, paul womack wrote:
I've been using Log4j succesfully for around 4 years now,
but I think I've recently hit a limitation.
I currently have multiple "leaf" loggers connected to multiple
appenders,
using additivity=false.
The appenders are all RollingFileAppenders.
This works fine.
I also have an "ErrorAppender". This is also a RollingFileAppender,
but the layout is a good deal more detailed. It also has a threashold
of "ERROR".
Each "leaf" logger is also connected to the ErrorAppender.
The upshot of all this is that each logger sends debug()
info() and warn() logging to its (1:1) Appender (AKA log file),
but any errors are logged both to the loggers "own" appender,
and to the ERROR appender, with much more information.
This all works nicely.
The practical upshot is, when something goes wrong,
I look in the error log file first.
But I'm having a performance issue. All this is used
under a heavily multi-thread tomcat context.
Given that doAppend in AppenderSkeleton is synchronized
to the Appender instance, and that the threshold is checked
inside doAppend, it appears to me (I'm about to try to confirm)
that every single log() call will synchronise on
the ErrorAppender instance, even if the logging is at the lowest
level.
The practical upshot is that every single log call becomes
a sync() on a global object.
That can't be good.
Is this a known issue, or is my analysis all wet?
Frankly, I'd be happy to be wrong on this one.
BugBear
Unfortunately, log4j 1.2 was designed in a era where concurrency was
not as significant a concern. Only one logging request can be in the
pipeline after a logging request passes the initial threshold tests
and is ready for dispatching to appenders. The impact can be
minimized by using AsyncAppender's to minimize the time spent in the
synchronized block.
There has been a desire, but no active development, for a log4j 2.0
that was designed for concurrency, JDK 5 and the all good things while
having a simple migration path for log4j 1.2 users. However, there
has never been the critical mass of developers ready at the same time
to make a go at it.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
