logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Smith <psm...@aconex.com>
Subject Re: log4j multithreading performance
Date Fri, 02 Dec 2005 02:42:05 GMT
LF5 has been removed in log4j1.3 (replaced by Chainsaw v2.

Paul

On 02/12/2005, at 1:39 PM, Trenton D. Adams wrote:

> Hi guys,
>
> Please don't take this as bad criticism.  I'm just trying to  
> provide some *useful* insights.  And besides, I think you guys are  
> doing a great job on log4j.
>
> I just read on the internet how log4j uses synchronized methods  
> everywhere.  I'm not too sure if it's true or not.  But, a grep of  
> the source shows me one place where it uses a synchronized method  
> when it shouldn't.
>
> It's located in LF5Appender.
>   protected static synchronized LogBrokerMonitor getDefaultInstance 
> () {
>     if (_defaultLogMonitor == null) {
>       try {
>         _defaultLogMonitor =
>             new LogBrokerMonitor(LogLevel.getLog4JLevels());
>         _finalizer = new AppenderFinalizer(_defaultLogMonitor);
>
>         _defaultLogMonitor.setFrameSize(getDefaultMonitorWidth(),
>             getDefaultMonitorHeight());
>         _defaultLogMonitor.setFontSize(12);
>         _defaultLogMonitor.show();
>
>       } catch (SecurityException e) {
>         _defaultLogMonitor = null;
>       }
>     }
>
>     return _defaultLogMonitor;
>   }
>
> As a general rule, singleton methods should not be synchronized for  
> performance reasons.  If this method is only called once in awhile,  
> no big deal.  But, if it's called regularly, then it can be a  
> really big performance problem.  Does the log4j project have coding  
> standards for such things?
>
> This particular singleton method should check the  
> "_defaultLogMonitor" for null first.  If it is not null, it should  
> return it.  If it is null, it should synchronize on some object,  
> perhaps LF5Appender.class.  Then it should check it for null  
> again.  If it is not null, it should return it.  If it is null, it  
> should construct it.
>
> Code from one of my singletons is below.  This code is guaranteed  
> to be thread safe, as well as be very high performing if it was  
> called multiple times from different threads.
>
>         if (commandFactory == null)
>         {
>             synchronized (CommandFactory.class)
>             {
>                 if (commandFactory == null)
>                 {
>                     try
>                     {
>                         commandFactory = new CommandFactory();
>                     }
>                     catch (Exception exception)
>                     {
>                         logger.info("error loading CommandFactory",  
> exception);
>                     }
>                 }
>             }
>         }
>
>
>         return commandFactory;
>
>
> I hope that helps.
>
> -- 
> Trenton D. Adams
> Systems Analyst/Web Software Engineer
> Navy Penguins at your service!
> Athabasca University
> (780) 675-6195
> :wq!
>
> __    This communication is intended for the use of the recipient  
> to whom it
>    is addressed, and may contain confidential, personal, and or  
> privileged
>    information. Please contact us immediately if you are not the  
> intended
>    recipient of this communication, and do not copy, distribute, or  
> take
>    action relying on it. Any communications received in error, or
>    subsequent reply, should be deleted or destroyed.
> ---
>
> ---------------------------------------------------------------------
> 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