directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <lis...@qos.ch>
Subject Re: [ApacheDS] General things to do for 1.0
Date Wed, 11 Jan 2006 11:53:21 GMT

Hello Emmanuel,

Here are a few short comments.

At 09:38 PM 1/10/2006, Emmanuel Lecharny wrote:
>Hi,
>
>here are some thougjt about Logs and what need to be done, what could be 
>done, and what I've in mind but that need agreement :
>1) Remove System.out from the base code (except for tests and may be for 
>clients). We have 129 of them, but only 24 are found in base code
>2) We must switch to NLog4j 1.2.21 for all the projects. Some of them are 
>using slf4j or commons-log, r nlog4j-1.2.17

You may want to consider slf4j instead of nlog4j. The slf4j API will allow 
the end user to switch between log systems by dropping in the appropriate 
jar file on the class path at deployment time. Moreover, slf4j will allow 
you to effortlessly use the successor of log4j when such a system becomes 
available.

>3) Check that every class that need a logger does it correctly.

This type of verification is always a good idea.

>4) Gather in a property file *all* the loggers

This may results in a high maintenance effort. It may be better to check 
the log output and suppress those log messages which are deemed too noisy.

>5) See if we can add some configuration is server.xml file to allow debug mode

This bears a directly relationship to the previous point (4). You would 
want to place the suppression instructions in a configuration file.

>6) Check that when log.debug is used, we have a if (log.isDebugEnabled())

Note that the if(log.isXYZEnabled() blocks are superfluous with 
parameterized printing methods available in the SLF4J API.

>7) check if we can add a mechanism (JMX?) to change the log level dynamically
>8) Add some cool appender like DatedFileAppender in the default configuration

If DailyRollingFileAppender is probably the best choice.

>9) Test the chainsawV2 tool
>10) Try to use a MessageFormat to store logs, and the use a 
>RessourceBundle file for error messages (I18n in mind) (beware of 
>synchronization pb !)
>11) Add a number for each message. For instance :
>* project org.apache.asn1 : 10000
>* project org.apache.directory.kerberos.common : 20000
>etc.
>and
>* FATAL : 0 -> 1999
>* ERROR : 2000 -> 3999
>* WARN : 4000 -> 5999
>* INFO : 6000 -> 7999
>* DEBUG : 8000 -> 9999
>
>Si if we have a message [24364], then we know that it's a project 
>org.apache.directory.kerberos.common message, and that's it's a WARN 
>level, and that it's number is 364.
>It will be totally useless for a human-being, but it will be very 
>interesting if we need to grep for some specific errors in a huge log 
>file. (I remember, years ago, having to chew a 2.7 Gbytes log file with 
>regexp to get the valuable infos out of it. Took 8 hours to get them, on a 
>very expensive server which has enough CPU and memory to do it during 
>night. Of course, I got many errors like "Connection failure", which were 
>totally useless, as we used this message for DB connection failures, Ldap 
>connection failures, EJB connection failures - wasn't my code, btw - ;)

You might want to consider the fact that most string search algorithms 
perform (linearly) better with longer search strings. So, searching for 
"ABCDEFGHIJKLMNOP" (16 letters) will be about 16 times faster than 
searching for just "A".  If you know the string to search for, which 
presumably will be longer than 5 letters (the length of the code), then 
searching for plain text should be faster. So, if adding a code for each 
message for speeding up searches is probably not a good idea.

>wdyt ?

Just my 2c.


-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



Mime
View raw message