Hadoop Common
  1. Hadoop Common
  2. HADOOP-9995

Consistent log severity level guards and statements

    Details

    • Type: Improvement Improvement
    • Status: Patch Available
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

             if (LOG.isDebugEnabled()) {
              LOG.info("Assigned container (" + allocated + ") "
      

      doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

      Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
      HDFS-1611 also corrected this inconsistency.
      This could have been avoided by switching from log4j to slf4j's {} format like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1), which gives cleaner code and slightly higher performance.

      1. HADOOP-9995-00.patch
        1 kB
        Jagadesh Kiran N
      2. HADOOP-9995.patch
        12 kB
        Jackie Chang

        Issue Links

          Activity

          Jackie Chang created issue -
          Jackie Chang made changes -
          Field Original Value New Value
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe level and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log statement is actually only printed out in DEBUG-level. Proposed improvements is attached.
          Jackie Chang made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Target Version/s 2.1.1-beta [ 12324807 ]
          Jackie Chang made changes -
          Status Patch Available [ 10002 ] Open [ 1 ]
          Jackie Chang made changes -
          Attachment HADOOP-9995.patch [ 12605179 ]
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe level and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log statement is actually only printed out in DEBUG-level. Proposed improvements is attached.
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log statement is actually only printed out in DEBUG-level. Proposed improvements is attached.
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log statement is actually only printed out in DEBUG-level. Proposed improvements is attached.
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. Proposed improvements is attached.
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. Proposed improvements is attached.
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. Existing previous issues try to correct this inconsistency. I am proposing a comprehensive correction over trunk.
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. Existing previous issues try to correct this inconsistency. I am proposing a comprehensive correction over trunk.
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          HDFS-1611 also corrected this inconsistency.
          Jackie Chang made changes -
          Link This issue is related to HDFS-1611 [ HDFS-1611 ]
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          HDFS-1611 also corrected this inconsistency.
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
          HDFS-1611 also corrected this inconsistency.
          This could have been avoid by switching from log4j to slf4j like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1).
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
          HDFS-1611 also corrected this inconsistency.
          This could have been avoid by switching from log4j to slf4j like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1).
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
          HDFS-1611 also corrected this inconsistency.
          This could have been avoided by switching from log4j to slf4j like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1).
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
          HDFS-1611 also corrected this inconsistency.
          This could have been avoided by switching from log4j to slf4j like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1).
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

          {code}
                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "
          {code}

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
          HDFS-1611 also corrected this inconsistency.
          This could have been avoided by switching from log4j to slf4j like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1).
          Jackie Chang made changes -
          Description Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

          {code}
                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "
          {code}

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
          HDFS-1611 also corrected this inconsistency.
          This could have been avoided by switching from log4j to slf4j like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1).
          Developers use logs to do in-house debugging. These log statements are later demoted to less severe levels and usually are guarded by their matching severity levels. However, we do see inconsistencies in trunk. A log statement like

          {code}
                 if (LOG.isDebugEnabled()) {
                  LOG.info("Assigned container (" + allocated + ") "
          {code}

          doesn't make much sense because the log message is actually only printed out in DEBUG-level. We do see previous issues tried to correct this inconsistency. I am proposing a comprehensive correction over trunk.

          Doug Cutting pointed it out in HADOOP-312: https://issues.apache.org/jira/browse/HADOOP-312?focusedCommentId=12429498&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12429498
          HDFS-1611 also corrected this inconsistency.
          This could have been avoided by switching from log4j to slf4j's {} format like CASSANDRA-625 (2010/3) and ZOOKEEPER-850 (2012/1), which gives cleaner code and slightly higher performance.
          Jackie Chang made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Allen Wittenauer made changes -
          Labels BB2015-05-TBR
          kanaka kumar avvaru made changes -
          Assignee kanaka kumar avvaru [ kanaka ]
          kanaka kumar avvaru made changes -
          Status Patch Available [ 10002 ] Open [ 1 ]
          Target Version/s 2.1.1-beta [ 12324807 ]
          Jagadesh Kiran N made changes -
          Assignee kanaka kumar avvaru [ kanaka ] Jagadesh Kiran N [ jagadesh.kiran ]
          Jagadesh Kiran N made changes -
          Attachment HADOOP-9995-00.patch [ 12747789 ]
          Jagadesh Kiran N made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]

            People

            • Assignee:
              Jagadesh Kiran N
              Reporter:
              Jackie Chang
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Development