JConsole: Monitor Mule App JVM in Local Environment

This document covers the capability of JConsole to monitor a MuleSoft App/API deployed in Local Environment. This tool is packaged with all JDKs and is super helpful in monitoring the Java Virtual Machine (JVM) in which MuleSoft deploys via Anypoint Studio. Developers can use this capability to check their application's performance even before deploying the API to CloudHub. Metrics like Heap Memory Usage, Threads, CPU Usage, etc., when available in the Local Environment, help with application optimizations and load testing.

To demonstrate this, I've created a sample Mule App that will stress the CPU & Memory of JVM to monitor the usage in JConsole.

Sample Mule Code

<ee:transform doc:name="CPU Stress" doc:id="34ec8c32-5795-4ad6-b966-5b38ab673052" >

  <ee:message >

    <ee:set-payload ><![CDATA[%dw 2.0

output application/json

fun fib(n) = if (n <= 1) n else fib(n - 1) + fib(n - 2)

---

fib(40)]]></ee:set-payload>

  </ee:message>

</ee:transform>

<ee:transform doc:name="Memory Stress" doc:id="5054bfe7-4428-45be-8e2e-b071472a9fdd" >

  <ee:message >

    <ee:set-payload ><![CDATA[%dw 2.0

output application/json

var bigArray = (1 to 1000000) map ((n) -> "Item-" ++ (n as String))

---

{

size: sizeOf(bigArray),

last: bigArray[-1]

}

]]></ee:set-payload>

  </ee:message>

</ee:transform>

Pre-requisites

Find out which JDK is being used by your Anypoint Studio. Click on the Window menu and open Preferences. Under the Java heading, click on Installed JREs.

Monitor Mule App

While keeping Anypoint Studio open in the background, head over to the bin directory of the JDK you have chosen and open/execute jconsole.

This will open the Java Monitoring & Management Console window. Make note of the processes under Local Process. You'll find multiple processes here because Anypoint Studio itself runs inside a JVM (there could be other programs on your PC running inside other JVMs, this is normal). Since we want to focus only on the PID (Process ID) corresponding to our Mule App, we use this window to differentiate. Click on the Cancel button.

Let's Debug our Mule App now.

Once the App is deployed, switch back to your JConsole window. Open the Connection menu and click on New Connection... option.

Please note that the PID of the deployed Mule App shown in the Anypoint Studio Console window and in the JConsole are not the same. This is why we start JConsole first before deploying the Mule App to identify its correct PID.

Now, select the PID (under Local Process) which was not present prior to deploying the App, and click on the Connect button. You'll receive a warning – Secure connection failed; proceed by clicking on the Insecure connection button.

This will hook your JConsole with the Mule App running in your local environment. You can now monitor various metrics of your deployed App here like Heap Memory Usage, Threads, CPU Usage, etc.

For demonstration, you can see that as I triggered the Scheduler Flow manually, it registered a CPU Usage spike in the JConsole graph.

Feel free to check out other tabs available in JConsole. For example, under the Memory tab, you can check other memory usage as well and use the Perform GC button to trigger Garbage Collection manually.

That's it.

Practical Use Case

Now, if you want to optimize your code for a specific Worker size, you can add VM arguments in Runtime configuration (Refer – Link; you can also use ChatGPT to create other configurations as needed). Pair this worker simulation with what you learned above, and you can build/optimize your integrations in the local environment itself.

Troubleshooting Common Issues

Make sure you identify Mule App's PID correctly. Apart from that, I don’t think anyone will encounter any issues using this guide, so I will leave the common issues part blank this time :)