geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [Logs] Re: Logging code and Garbage Collection
Date Thu, 14 Aug 2003 22:02:46 GMT
I have just checkin in a proof of concept CachingLog4jLog.  This 
commons log implementation caches the values of the trace, debug, and 
info enabled flags.  The flags are update on a periodic basis by a 
single java.util.Timer.  The period is currently hard coded to 3 
minutes, but if people like this I can add a management interface to it.

The warn, error and fatal levels are hard coded to true as log4j does 
not even expose a isXXXEnabled for these levels.  The internal 
implementation of the trace, debug, and info methods do an explicit 
level check before delegating the the log4j logger.  For example:

     public void info(Object message) {
         if (infoEnabled) {
             logger.log(FQCN, Priority.INFO, message, null);


On Thursday, August 14, 2003, at 03:14 AM, Alex Blewitt wrote:

> On Thursday, Aug 14, 2003, at 06:31 Europe/London, Pasi Salminen wrote:
>> Putting my administrator hat on, I must say that I don't like 
>> application servers
>> which do not enable change of logging level at runtime.
> Though personally I've not come across this before, I can see that it 
> would be a desirable thing to have.
>> Berin Loritsch wrote:
>>> For example:
>>> if ( m_logger.isDebugEnabled() )
>>> {
>>>      m_logger.debug( "test message" );
>>> }
>>> is both slower and more cumbersome than this:
>>> m_logger.debug( "test message" );
> I will agree that there is more code. But bear in mind that w/o the 
> debugging guard, the m_logger.debug("message") will almost certainly 
> call m_logger.isDebugEnabled() (or access the boolean to do the test) 
> anyway, so in the (common) case when debugging isn't enabled then IMHO 
> it will make very little difference; possibly even run /faster/ with 
> the guard.
> Bear in mind that 'is slower' and 'is faster' are only likely to be 
> based on what we humans think; until you've actually got code that is 
> running, and it is demonstrable that this is where the bottleneck is, 
> then pre-optimisation isn't worthwhile.
> Alex.

  * Dain Sundstrom
  * Partner
  * Core Developers Network

View raw message