0.7 Release

It’s autumn already and many things happened since Penna was announced and latest activity surfaced. This doesn’t mean that Penna stalled, just that a lot of work has been happening in the background.

And it is now time to announce the great new features & improvements that are expected to be in this exciting 0.7 release!

Native MDC implementation

This is one of the features I am the most excited to announce!

Up until Penna 0.6, we were using the BasicMDCAdapter from slf4j, which works great, but limits our ability to optimize. With this new release, we have a, still very basic MDC adapter implementation that already allows us to be more lean on managing the key-value pairs added on to the MDC.

The theme of the 0.7.x branch will definitely be iterating over the MDC, making sure it is both correct and fast.

Better control over exception logging

Exceptions are highly hierarchical and, because of that, we can go through a very long list of exceptions or, even worse, fall into a closed-loop relationship between exceptions. This release of Penna adds a limit to the amount of layers down exception logging can go.

This is a simple and fast way to cut out of cycles and extends our bloom filter implementation.

Quick note on the bloom filter: Its idea is allow us to quickly determine if we already printed a certain log line, cutting the stacktrace short at the repetition point. In this release, it is also configurable, by setting the deduplication flag on the ExceptionHandling class to false.

Finally, one can also determine a hard limit to the stacktrace through maxDepth, ensuring that even if we get enough unique lines in the stacktrace, it won’t write more than what’s needed.

Internal restructure

If you’re reading the source code you’ll notice that the code that manages writing the json object to stdout has been moved around, renamed and refactored. This allows for two very important changes for this and the upcoming releases:

• Better performance for the default logger;
• Initialization-time rebinding of the sink;

Many of the original assumptions of Penna simply proved to be wrong. For example, using the Emitter functional interface sounded like a good idea, but modern java’s switch is pretty capable of delivering amazing performance.

Another small but important win is the resizing of the internal buffer, which seems to be more correct now.

Finally, many of the calculations and values were antecipated to reduce what was needed to be done when prompted to write log.

If you’re interested in those fixes, how I got to them, how I measured and their impact, let me know.

The second benefit is to allow for rebinding the Sink. This is huge as it allows for other log formats to be applied on top of the existing logic, replacing a much smaller piece of the machinery. It will be necessary for the upcoming Elastic Common Schema support, but also allows for the last exciting feature of this release…

Development mode

One of the earlier requests was to enhance the readability of logs during development. It’s understandable that when running tests, mentally parsing timestamps or trying to locate the log messages within JSON can be challenging. Our goal is to offer the best of both worlds: logs that are fast during app runtime and user-friendly during app development.

By dropping this single jar into your test runtime, you get the benefits of the new Sink:

1
2

// Add this line to your project's dependencies
testRuntimeOnly "com.hkupty.penna:penna-dev:0.7.0-alpha4"

So, what’s with the colors you might ask? penna-dev has a unique philosophy: Loggers, MDC Keys and Key-value argument keys will be deterministically colored by their value. This means that it is easier to identify which loggers wrote which message, for example.

This is another area where improvements will come in the future, with the ability to control the log level granularly in runtime, exclude loggers from the output and other quality of life focused features for improving the experience during development time.

Final words

During this 0.7.x cycle the focus will of course be on MDC and penna-dev, with focus on stabilizing those features for the next 0.8.x branch to start early next year. Next up is ECS, as mentioned and implementing native marker support.

Also, with the release of JDK 21, some more internal restructuring might be necessary do adapt to a world of virtual threads.

Have you missed anything? Any suggestions or thoughts? Don’t refrain from opening an issue or starting a discussion, your feedback is appreciated!