Mimicking Java Flight Recorder Triggers Outside Java Mission Control
By Jim Connors - 28 July 2017

As highlighted in this previous article, Java Flight Recorder triggers enable you to selectively dump detailed runtime information about your Java application when user-defined conditions are met.  In order to take advantage of this powerful feature, you must create and enable trigger rules inside the Java Mission Control client.  For one or a very small number of applications, using Java Mission Control might be acceptable, however if you need to manage a large number of applications, the notion of keeping a Mission Control client open for each application instance might not be very appealing or realistic.

Unfortunately, use of Flight Recorder triggers currently only works within the Mission Control client.  So the question becomes, is it possible to mimic trigger-like behavior outside of Mission Control?  This article aims to show how you can, with a simple JMX client program and some scripting.  The following README.txt file is part of the included framework and provides a reasonable description of its individual components.  It also instructs the user as to how to run the demonstration.  The framework is bundled as a NetNeans project and can be downloaded here.

To cut to the chase, here's a simple example of how the framework might be used.  For this example, we'll use a sample Java application called Latencies. This program has a deliberate flaw in that as the user increases the number of threads, the latency dramatically increases too.  What we'd like to do is mimic a trigger which will result in a dump of the Java Flight Recorder information when our thread count crosses a certain threshold.  Here are the steps:

1. Unzip the jmxclient.zip file. For this example, we unzip the jmxclient.zip file in the d:\tmp directory, resulting in the creation of the d:\tmp\JMXClient directory.

2. Start NetBeans and open up the JMXClient project that was just unzipped in the d:\tmp\JMXClient directory

3. Within NetBeans "Clean and Build" the JMXClient project.

Let's take a look at the command-line options associated with running the Latencies program:

• -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false - this enables an agent to remotely monitor, via JMX, the Latencies program at port 9999.
• -XX:+UnlockCommercialFeatures -XX:+FlightRecorder - these two options must be added to enable the Flight Recorder capability.
• -XX:FlightRecorderOptions=defaultrecording=true - this puts the Latencies program in Flight Recorder continuous recording mode, that is to say, telemetry data will continuously be recorded and stored in a circular buffer.  At any point in time, through a variety of means, the Flight Recorder data can be dumped to a file.

5. With the Latencies program running, open up another CMD shell and start the JMXClientThreadCount.bat script.

Again, let's examine the command-line arguments to this program:

• D:\Oracle\jdk8\bin\java.exe -cp JMXClient.jar com.example.jmxclient.JMXClientThreadCount - com.example.JMXClientThreadCount is the Java main class found in JMXClient.jar
• -debug - logs debug information to the console.  Among the information displayed is the URL (hostname and port number) it uses to connect to the JMX server (the Latencies program), and additionally it logs the value of the ThreadCount MBean each time the program polls that information.
• -interval:2000 - instructs the program to poll the value of the ThreadCount bean every 2 seconds (2000 milliseconds)
• -threshold:20 - instructs the program to terminate when the ThreadCount value exceeds 20.

6. With both programs running, return back to the Latencies window and hit <Enter> 4 or 5 times to add additional threads to the program.