Understanding Stack Traces in Mule

byGonzalo Marcos -
A stack trace is a report of the active stack frames at a particular point in time during the execution of a program. It is typically displayed when an error or exception occurs in the code, showing the sequence of function calls that led to the error.
Using stack traces and thread dumps in MuleSoft can be critical for diagnosing and resolving issues in your Mule applications, especially in complex integrations or when your application is deployed in production

Stack traces in MuleSoft are similar to those in other Java-based environments. When an error occurs in your Mule application, a stack trace is generated, showing the series of method calls that led to the exception.

In MuleSoft, stack traces are typically found in the logs when an exception occurs. They are particularly useful for pinpointing where the error originated in your flow, especially when dealing with complex transformations, connectors, or custom Java components.

Understanding Stack Frames

What do we mean with active stack frames? With that we refer to the current state of the execution of a thread at the moment the stack trace is captured. Each entry in the stack trace represents a stack frame, and these frames show the sequence of method calls that the thread is executing. To be more specific:

  • A stack frame represents a method call and contains information about the method’s local variables, parameters, and the execution state of the method.
  • Each stack frame is pushed onto the call stack when a method is invoked and popped off when the method returns.
  • The active stack frames are the stack frames that are currently active on the call stack when a stack trace is generated.
  • They reflect the exact path of execution from the thread’s entry point to the point where the stack trace was captured. They are essentially the "snapshot" of the execution path at that moment.
  • The stack frames are listed in reverse order in the stack trace, with the most recent method call at the top and the earliest at the bottom.

Key Components of a Stack Trace:

  • Exception/Error Message: The type of exception or error and possibly a brief description of what went wrong.
  • Stack Frames: As explained above, these are the entries in the stack trace. Each stack frame shows:
    • The method or function that was called.
    • The file name where the method or function is defined.
    • The line number in the file where the call occurred.
  • Call Hierarchy: The stack trace lists the calls in the order they were made, starting with the most recent call (usually the one that caused the error) at the top and going back through the call history.

Where to Find Stack Traces:

  • Anypoint Studio: When running a Mule application in Anypoint Studio, stack traces will appear in the Console view whenever an error is encountered.
  • Logs: If the application is deployed to a Mule Runtime, Runtime Fabric or CloudHub, the stack traces will be logged in the application logs. These can be accessed via the CloudHub logs tab or by connecting to the Mule Runtime’s log files on-premises. (see below).

How to Use Stack Traces for Debugging:

  • Analyze the Trace: Start from the top of the stack trace to identify the last method or flow component that was executed. Look for familiar classes or Mule components that relate to your flow.
  • Locate the Error: Use the file name and line number provided in the stack trace to locate the exact spot in your flow where the error occurred.
  • Understand the Exception: The type of exception and accompanying message will give you clues as to what went wrong (e.g., NullPointerException, ConnectionException, etc.).
  • Fix the Issue: Based on the information in the stack trace, make the necessary changes to your Mule flow or configuration.

Example in Java:

Here’s an example of a stack trace and an explanation of the active stack frames:
Exception in thread "main" java.lang.NullPointerException
at com.example.MyClass.myMethod(MyClass.java:42)
at com.example.MyClass.doSomething(MyClass.java:28)
at com.example.Main.main(Main.java:15)
These are the active stack frames that we’ve captured when the stack trace was generated
  • com.example.MyClass.myMethod(MyClass.java:42):
    • This is the topmost frame and represents the most recent method call that threw the exception.
    • MyClass.java is located at line 42.
    • This frame is active because the method myMethod was executing when the exception occurred.
  • com.example.MyClass.doSomething(MyClass.java:28):
    • This is the method that called myMethod.
    • MyClass.java is located at line 28.
    • This frame is also active and represents the method that invoked myMethod, leading to the exception.
  • com.example.Main.main(Main.java:15):
    • Description: This is the entry point of the application where the method doSomething was called.
    • Location: Main.java at line 15.
    • Status: This is the bottom-most active frame, indicating the start of the call chain.

Configuring Stack Traces in Mule

Mule does not display all stack traces by default. The traces that we see in our logs filter out some internal class references to produce a more readable output. 
But if needed, for debugging or troubleshooting, we can set it up to get full strack traces. There are different ways depending the type of deployment and status of the app:
  • Via command-line arguments for apps in Standalone Runtimes
  • Using properties in Anypoint Studio for apps in dev
  • Using Properties in Runtime Manager for running applications
  • Using a flag in Maven at build

Via command-line arguments:

We need to add the  -M-DpropertyName property with the following arguments to control the behavior of stack traces:
  • mule.verbose.exceptions - If set to true, Mule shows filtered stack traces.
  • mule.stacktrace.filter - A comma-separated list of packages and/or classes to remove from the stack traces, which are matched using string.startsWith().

In Anypoint Studio

In Studio, you can set the properties specified above to instruct Mule to provide stack traces and to filter out packages or classes to remove. To adjust these settings:
  • Select Run > Run Configurations…
  • Define the properties to specify the behavior you want.
  • In the example below, the mule.verbose.exceptions property is set to true.

In Cloudhub 1.0 and Cloudhub 2.0

  • Similar to Anypoint Studio we need to provide that argument value in the form of a runtime property in Runtime manager.
  • For that, go to the details of your app > Settings > Properties tab and add mule.verbose.exceptions=true as a property

In Maven

  • At build we can pass that argument is as a flag into the mvn command: For example
mvn test -Dmule.verbose.exceptions=true
  • We can also deploy an app with the full stack trace enabled. To do that we can create a property in the pom file which will be picked up at deployment time. For that we would add it like this within the properties and configuration tags:
...
<configuration> 
    ... 
    <properties> 
        <mule.verbose.exceptions>true</mule.verbose.exceptions> 
    </properties> 
<configuration> 
...
Previous Post Next Post