Logging Feature of MicroStream Version 7

With version 7 of MicroStream, there was the addition of logging statements throughout the codebase. These logging statements give you feedback on the important lifecycle actions that are performed by the MicroStream components. And can help you identify the low-level steps that are performed when reading or storing Java objects from the data storage.

We have chosen to perform the logging through the SLF4J framework. This allows you as a developer to integrate it into the logging of your choice in your project. It also has a very good backward compatibility strategy so that you don’t need to use the exact same version of the framework that we have used in the MicroStream codebase.

What is Logged?

There are two sets of actions logged by the MicroStream code. The first set is about the lifecycle of the components. When the Embedded Data Storage, Type Manager, Lazy Reference Manager, etc .. is started and stopped, this info is shown with level INFO.

This gives you an idea of when the initialization and shutdown take place for example and can give you some indications if multiple managers are started that might not be the intention of your code.

The second group of events is the low-level actions that are performed. When data is read from the storage, types are looked up, buffers created or enlarged, etc… you can get a message for each of them. These low-level information messages are mainly interesting for our development team but can also be beneficial for you as a developer using the MicroStream project. They can be used to tune the system for optimal performance for example.

This information is shown with level DEBUG and thus by default not visible in the log. You need to adjust the log level so that they appear. We don’t recommend this setting in production as there will be many messages that will affect the performance of the application.

Configuring the Log

For those that already make use of the SLF4J logging facade, you are already familiar with how you should use it. The SLF4J project doesn’t perform the actual logging and delegates this to the Java Util Logging of the JVM, Log4J, Logback, the SLF4J simple implementation, or any other library that implements the API and can be discovered using the binding mechanism.

So the configuration depends on the library that you have chosen for your project. Each of them allows you to configure the log level for a certain package using a configuration file or programmatically.

When using the LogBack library and the configuration is performed through an XML file, the following line will result in having all MicroStream log messages in the log.

<logger name="one.microstream" level="DEBUG" />

No Log Messages Wanted

Of course, it is also possible to disable the log messages completely. The way you can do this depends if you already make use of SLF4J in your project or not.

In case you use SLF4J and a specific logging framework, you can set the Log level to OFF to disable all messages from appearing in the log. In the situation of the XML configuration with LogBack, the following line results in disabling the logging functionality of MicroStream.

<logger name="one.microstream" level="OFF" />

When you do not make use of SLF4J yet, you will see the following lines appear on the System Error stream of the JVM.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

This warns the user that the application contains only the API dependencies of SLF4J, coming as a transitive dependency of MicroStream itself and that no logging library is found that can write out the messages.

This doesn’t affect the functionality of MicroStream nor the application. Everything will keep on working as expected. But maybe you find the error messages annoying or your company policy indicates that such messages are not allowed in production. In that case, you can add the NOP (no-operation) artifact of SLF4J to your project. This is actually an implementation of the API but it swallows any message. It is a very small jar file of around 4000 bytes but the end result is that SLF4J is silenced.

<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-nop</artifactId>
   <version>1.7.32</version>
</dependency>

Version number 1.7.32 is chosen here as that is the version that is used within the MicroStream codebase.

Version Mismatch?

Is there a problem when your project uses another version of SLF4J? No, there is no problem because SLF4J makes sure that all versions of the API are compatible. You might need to tweak the Maven project file a bit to make sure everything keeps on working perfectly.

The API is backward compatible, but the binding with a certain logging framework like Log4J or Logback might need a specific version range of the API before it works correctly.

Since we bring in the SLF4J API as a transitive dependency, it might be the case that Maven chooses our version of the API to include in the final artifact of your project and not the version that you have specified. Even when the version in your project is more recent than the version that is included in MicroStream. This can be easily overcome by defining the version of the SLF4J API in the dependency management section of the pom.xml file.

<dependencyManagement>
   <dependencies>
      <dependency>
         <groupId>org.slf4j</groupId>
         <artifactId>slf4j-api</artifactId>
         <version>${slf4j-version}</version>
      </dependency>
   </dependencies>
</dependencyManagement>

Having the above snippets enforces the version defined in the property `slf4j-version` for Maven. And also when this is an older 1.6.x or newer 2.0.0 version, MicroStream log messages will still appear in the log file.

Conclusion

The addition of the logging functionality within the MicroStream codebase is a small feature but can be very helpful in some scenarios. You will get more insight into what the persistence engine is doing and can be used to optimize your environment.
We have chosen SLF4J since that gives you the most flexible options for the integrations and configuration within your project. And due to the binary compatibility of the SLF4J API, there are also no version conflicts if you are using another version of this logging facade.