JXInsight/Simz – Write Once, Load Once, Plugin Everywhere

One of the primary design goals for JXInsight/Simz was that all custom plugins using the Probes Open API would be able to work in a single JVM runtime as well as a simulated multi-JVM runtime without any code changes whatsoever. The only difference is that a custom plugin loaded by the JXInsight/Simz service would be able to observe the metering of threads across multiple JVM runtimes from within a single runtime as calls to the Probes API are replayed in near real-time. Write Once. Run in one JVM. Plug into every JVM.

To demonstrate how seamless this truly is lets create a custom metering plugin that prints out the name of a thread the very first time it is registered with the metering runtime which typically happens just before the execution of the first instrumented method by a thread.

Here are the system properties that need to be added to a jxinsight.override.config file to load the custom metering plugin within a metered runtime.

Lets now create a sample application which will be instrumented and metered by JXInsight/OpenCore.

A single line is placed in a jxinsight.aspectj.filters.config instructing the agent to only instrument classes in the acme.* package(s).

Finally the script to run up 3 Java runtimes each given a different thread name argument.

Here is the output from running the script with the above custom metering plugin printing out 2 lines for both the main and argument named thread per JVM runtime execution. It is important to note that the custom metering plugin is collocated with the application.

Lets now disable the loading of the custom metering plugin and instead enable the simz client metering extension which will re-route calls into the Probes Open API to a remote JXInsight/Simz service. Unless specified the extension assumes the service is running on the same host.

The JXInsight/Simz service operates identical to a metered runtime and so the custom metering plugin properties can be simply copied over to a jxinsight.override.config file located in the services jxinsight.home directory.

Here is the script needed to launch the JXInsight/Simz service with the custom metering plugin available on the classpath. Note there are no requirements to have the actual application classes available as this JVM runtime only simulates the behavior on threads in terms of metering (probes, meters, readings,…).

The output from the client script now only lists those System.out.println() calls made by the application and not the custom metering plugin.

In the JXInsight/Simz JVM runtime the custom metering plugin observes the metering of threads across each of the 3 simz client connected JVM runtimes. The global remote observation is achieved without any code changes.

Changing the custom metering plugin to output the name of the Probes.Context will allow us to see the UUID associated with each simz client connected JVM runtime.

Here is a sample of the JXInsight/Simz output with this change applied to the custom metering plugin.

Alternatively the Probes.Environment interface associated with the Probes.Context interface can be used to lookup up the server UUID in both real and simulated environments.

Click here to see a screen recording walking through the above steps within a Java IDE.