You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Kirk Lund (Jira)" <ji...@apache.org> on 2021/04/15 16:20:00 UTC

[jira] [Updated] (GEODE-9152) Logging statements using log markers should be INFO level

     [ https://issues.apache.org/jira/browse/GEODE-9152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kirk Lund updated GEODE-9152:
-----------------------------
    Description: 
Logging statements using log markers should be INFO level.

Having log markers at TRACE or DEBUG is worthless because you have to set the log-level to TRACE and also enable that log marker which will fill the disk with logging.

All of the logging statements with log markers should be changed to INFO level. Then having the log-level set to INFO and enabling the log marker will enable that log statement which is the expectation that most users and developers have.

In Geode, all log markers are defined in geode-core/src/main/java/org/apache/internal/logging/log4j/LogMarker. The ideal test would simply be a LogMarker test which enables one LogMarker at a time and verifies that logging it at INFO level results in it being logged as expected. Then all uses of that LogMarker should be changed to INFO level. I don't think every class using that LogMarker needs to have tests for enabling or disabling it.

FastLogger in geode-logging will require the addition of one method to avoid any performance degradation:
{noformat}
  @Override
  public boolean isInfoEnabled(Marker marker) {
    return delegating && super.isInfoEnabled(marker);
  }
{noformat}

  was:
Logging statements using log markers should be INFO level.

Having log markers at TRACE or DEBUG is worthless because you have to set the log-level to TRACE and also enable that log marker which will fill the disk with logging.

All of the logging statements with log markers should be changed to INFO level. Then having the log-level set to INFO and enabling the log marker will enable that log statement which is the expectation that most users and developers have.

In Geode, all log markers are defined in geode-core/src/main/java/org/apache/internal/logging/log4j/LogMarker. The ideal test would simply be a LogMarker test which enables one LogMarker at a time and verifies that logging it at INFO level results in it being logged as expected. Then all uses of that LogMarker should be changed to INFO level. I don't think every class using that LogMarker needs to have tests for enabling or disabling it.


> Logging statements using log markers should be INFO level
> ---------------------------------------------------------
>
>                 Key: GEODE-9152
>                 URL: https://issues.apache.org/jira/browse/GEODE-9152
>             Project: Geode
>          Issue Type: Bug
>          Components: logging
>            Reporter: Kirk Lund
>            Priority: Major
>
> Logging statements using log markers should be INFO level.
> Having log markers at TRACE or DEBUG is worthless because you have to set the log-level to TRACE and also enable that log marker which will fill the disk with logging.
> All of the logging statements with log markers should be changed to INFO level. Then having the log-level set to INFO and enabling the log marker will enable that log statement which is the expectation that most users and developers have.
> In Geode, all log markers are defined in geode-core/src/main/java/org/apache/internal/logging/log4j/LogMarker. The ideal test would simply be a LogMarker test which enables one LogMarker at a time and verifies that logging it at INFO level results in it being logged as expected. Then all uses of that LogMarker should be changed to INFO level. I don't think every class using that LogMarker needs to have tests for enabling or disabling it.
> FastLogger in geode-logging will require the addition of one method to avoid any performance degradation:
> {noformat}
>   @Override
>   public boolean isInfoEnabled(Marker marker) {
>     return delegating && super.isInfoEnabled(marker);
>   }
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)