[ https://issues.apache.org/jira/browse/HADOOP-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899442#action_12899442 ] 

Doug Cutting commented on HADOOP-6884:
--------------------------------------

As Luke implies, slf4j already implements the API style I proposed above:

http://www.slf4j.org/faq.html#logging_performance

As for commons logging, there are a large number of articles suggesting that it should not be revived:

http://articles.qos.ch/thinkAgain.html
http://tapestryjava.blogspot.com/2007/08/so-long-commons-logging-hello-slf4j.html

So, to my thinking, a good approach might be:
 - switch to slf4j
 - replace string concatenation with slf4j format strings
 - add a checkstyle or other test that warns about string concatenation in log expressions
 
> you also need to choose at redist time what your back end will be and include that JAR

Unless we want to break things incompatibly, Hadoop's standard logging backend will remain log4j for the forseeable future.  So slf4j is only being proposed here as a front end API.  To my thinking, the question is whether we should invent our own improved front-end API for log4j that makes it easier to be efficient, or whether we should just use an existing efficient API like slf4j.  I lean towards the latter.



> Add LOG.isDebugEnabled() guard for each LOG.debug("...")
> --------------------------------------------------------
>
>                 Key: HADOOP-6884
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6884
>             Project: Hadoop Common
>          Issue Type: Improvement
>    Affects Versions: 0.22.0
>            Reporter: Erik Steffl
>            Assignee: Erik Steffl
>             Fix For: 0.22.0
>
>         Attachments: HADOOP-6884-0.22-1.patch, HADOOP-6884-0.22.patch
>
>
> Each LOG.debug("...") should be executed only if LOG.isDebugEnabled() is true, in some cases it's expensive to construct the string that is being printed to log. It's much easier to always use LOG.isDebugEnabled() because it's easier to check (rather than in each case reason whether it's necessary or not).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.