Page History

...

Driving requirements: a) improve debugging by introducing full-qualified class name categories, mapped diagnostic contexts, markers, filters, flow tracing, static loggers and other features missing in GemFire logging, b) improve integration with customer applications and deployment environments such as Tomcat/tcServer, c) provide industry standard logging API as requested by many customers and field engineers, d) improve code maintenance by replacing deficient proprietary logging with free, open-source, modern logging library, e) select the best performing library that meets the requirements.

Note that Log4J2 was chosen for the logging backend instead of LogBack because Log4J2 processes disabled DEBUG statements faster at INFO level than LogBack does. When comparing logging throughput at DEBUG level, LogBack was slightly faster, but when comparing overall impact to application performance Log4J2 was faster. In other words, GemFire using Log4J2 out-performed GemFire using LogBack at INFO level or above. Since INFO level or above is expected for production systems, Log4J2 was chosen over SLF4J and LogBack. GemFire code base will use Log4J2 API while the custom logging appenders for LogWriter-style rolling and Alerts will use Log4J2 Core.

2 Bugs and Feature Requests 

This section lists the Bugs and Feature Requests that also need to be addressed as part of this overall effort:

• • 2.1 #47722 1 #47722 G0 Configurable option of appending to log file or creating new file
  • 2.2 #50483 2 #50483 F0 log file size does not account for user/application logging
  • 2.3 #51111 3 #51111 F0 Web application (Tomcat) logging goes to gemfire log
  • 2.4 #47910 4 #47910 R2 <Regression> ConcurrentModificationException in createLogWriter during locator startup.
  • 2.5 #51207 5 #51207 F2 Improve logging configuration for libraries
  • 2.6 #40414 6 #40414 R3 i18n changes (toLocalizedString) causes ports, ids to be formatted with commas
  • 2.7 #43396 7 #43396 R3 Remove dead messages from LocalizedStrings and fix any obvious typos
  • 2.8 #51197 8 #51197 C2 A log file name with no '.log' extension causes the gfxd connect to fail after the first time
  • 2.9 #45796 9 #45796 F3 Feature Request:Adding a Functionality to Make Logging Custom Filter Available in Gemfire

Introducing Log4J 2 as our underlying logging library satisfies 2.1. #47722 and 2.5. #51207. In addition it makes 2.4. #47910 go away.

...

• MDC -- Mapped Diagnostic Context which is an optional ThreadLocal map of value(s) that can be used for detailed debugging and tracing

5 Selection of Log4J 2

• used for detailed debugging and tracing

5 Selection of Log4J 2

Log4J 2 is a complete overhaul of Log4J incorporating the best changes introduced by SLF4J. It separates the library into two primary jars: log4j2-api and log4j2-core. Log4J 2 provides a much more versatile library than SLF4J and is much more customizable. Our selection is driven by the need to customize logging and its reported performance characteristics. We are not advocating async loggers which are present in some form in both Log4J 2 and LogBack. Log4J 2 improves performance dramatically over Log4J 1.x as well as SLF4J. For reasons of customization we had to select Log4J 2 and its performance helped solidify that decision.

Note that Log4J2 was chosen for the logging backend instead of LogBack because Log4J2 processes disabled DEBUG statements faster at INFO level than LogBack does. When comparing logging throughput at DEBUG level, LogBack was slightly faster, but when comparing overall impact to application performance Log4J2 was faster. In other words, GemFire using Log4J2 out-performed GemFire using LogBack at INFO level or above. Since INFO level or above is expected for production systems, Log4J2 was chosen over SLF4J and LogBack. GemFire code base will use Log4J2 API while the custom logging appenders for LogWriter-style rolling and Alerts will use Log4J2 CoreLog4J 2 is a complete overhaul of Log4J incorporating the best changes introduced by SLF4J. It separates the library into two primary jars: log4j2-api and log4j2-core. Log4J 2 provides a much more versatile library than SLF4J and is much more customizable. Our selection is driven by the need to customize logging and its reported performance characteristics. We are not advocating async loggers which are present in some form in both Log4J 2 and LogBack. Log4J 2 improves performance dramatically over Log4J 1.x as well as SLF4J. For reasons of customization we had to select Log4J 2 and its performance helped solidify that decision.

For more information, please see The Logging Olympics – A Race Between Today’s Top 5 Java Logging Frameworks

...

7.10.1 Removal of OSProcess.redirectCOutput. We will remove the default use of this. The LogWriterAppender will not have stdout and stderr redirected to. Should we retain this and only enable it based on an undocumented system property? (Kirk: probably not) This is primarily to satisfy:

• • #51111 F0 Web application (Tomcat) logging goes to gemfire log

• • #50483 F0 log file size does not account for user/application logging

8 Feature Interactions

8.1 GFSH

...