Thread by @denis_makogon

#JavaTuesdayThread

Today I’d like to speak a bit regarding #Java Flight Recorder (JFR) and how far you can get with it. #OpenJDK #JFR #JMC

So, as you may know, a few releases ago, Java developers were able to create, publish, and react to particular JDK events, also known as JFR.

The first and most important JFR feature is that the whole JDK is pierced with tons of JFR events. You can enable them to get most of the information about what’s going on with the JVM.

Another valuable feature is the ability to create custom events of different nature. The JDK JFR framework does not enforce developers regarding the type and the nature of events, so, most events are free-form classes that extend "jdk.jfr.Event" class.

Recently, I decided to explore how complicated it is to implement a resource state-tracking event. Meaning, that a certain entity will emit events based on some state of an object through its lifecycle.

In my case the idea was to track how many actively running threads are in the thread pool provided in the form of an executor to the HTTP server whose purpose is to run long-running math operations like FIPS-140-3 tests against certain bite-sequences:

The biggest challenge is that ExecutorService doesn’t provide API methods to know how many threads are up and running at a particular moment. So, to bypass the problem, we’d have to wrap an executor accompanied by an atomic counter:

In order to make the most negligible impact against executor service and the code running in threads, the easiest trick is to enhance the executor with a service thread that will process the value of an atomic counter and build stats out of it:

By enabling this event in the recording stream, we can observe how often the amount of actively running threads is changing through the lifecycle of an executor service:

And later on, those events can be observed in Java Mission Control:

Another massive topic with the JFR is: is it really a good idea to turn a subscriber-based operation model (you can only react to the particular event) into a poll-based model...

... i.e., build an interface between JFR and server metrics that can be consumed more straightforwardly than JMX socket-based interface just on purpose for JFR event streaming.

If it’s possible and really makes a lot of sense then it will significantly simplify application metrics emitting and consuming within 3rd-party metering services over HTTP in a cloud (VMs, K8s, etc).