logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Multithreading issues - doAppend is synchronised?
Date Sun, 08 Nov 2009 20:06:21 GMT

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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message