Monitoring Deserialization via JFR – Java I/O: Context-Specific Deserialization Filters

136. Monitoring Deserialization via JFR

JFR stands for Java Flight Recorder and it is an event-based tool for diagnosis and profiling Java applications. This tool was initially added in JDK 7 and since then it was constantly improved (for instance, in JDK 14, JFR was enriched with event streaming, and in JDK 19, with filtering event capabilities).Among its reach list of events, JFR can monitor and record deserialization events (the Deserialization Event). Let’s assume a simple application like the one from Problem 124 (the first problem of this chapter). We start configuring JFR for monitoring the deserialization of this application by adding in the root folder of the application the following deserializationEvent.jfc file:

<?xml version=”1.0″ encoding=”UTF-8″?>
<configuration version=”2.0″ description=”test”>
  <event name=”jdk.Deserialization”>
    <setting name=”enabled”>true</setting>
    <setting name=”stackTrace”>false</setting>
  </event>
</configuration>

Practically, this file instructs JFR to monitor and record the deserialization events.Next, we use -XX:StartFlightRecording=filename=recording.jfr to instruct JFR to record output in a file name recording.jfr, and we continue with settings=deserializationEvent.jfc to point out the configuration file listed previously.So, the final command is the one from this figure:

Figure 6.2 – Running JFR

After this command is executed, you’ll see an output as in figure 6.3:

Figure 6.3 – The output of our application

JFR has produced a file named recording.jfr. We can easily view the content of this file via JFR CLI. The command (jfr print recording.jfr) and the output are available in figure 6.4:

Figure 6.4 – The output of JFR containing deserialization information

JFR produced a single deserialization event since our application has performed a single serialization/deserialization cycle of a Melon object. You can see the type of the object (here, Melon) via the type field. Since the Melon instance is not an array, the arrayLength was set to -1 which means that arrays are not applicable. The objectReferences represents the first object reference in the stream (so, 1) and the bytesRead represents the number of bytes read from this stream (in this case, 78 bytes). We also see that there was no filter present, filterConfigured = false, and filterStatus = N/A (Not Applicable). Moreover, exceptionType and exceptionMessage are N/A. They are not applicable because there is no filter present. They are useful to capture any exceptions caused by a potential filter.Besides the JFR CLI, you can use more powerful tools for consuming the Deserialization Event such as JDK Mission Control (https://www.oracle.com/java/technologies/jdk-mission-control.html) and the well-known Advanced Management Console (https://www.oracle.com/java/technologies/advancedmanagementconsole.html).

Summary

In this chapter, we have covered a bunch of problems dedicated to handling Java serialization/deserialization processes. We’ve covered from classical problems to JDK 17 context-specific deserialization filters passing through JDK 9 deserialization filters.