Welcome to Day 0 of our journey into optimizing Boomi performance! In the intricate tapestry of the Boomi ecosystem, the Integration application emerges as the linchpin, offering a versatile canvas where Boomi processes come alive. These processes, like a symphony of components, intricately weave together connectors, logic elements, and data processing modules. Crafted with precision by Boomi developers, these components coalesce into a dynamic workflow, effectively encapsulating the intricate business logic of the integration.

Simulation Setup – Boomi Performance Environment

The heartbeat of this orchestrated dance lies in the deployment to a specific environment. Boomi environments, whether a singular atom or a dynamic molecule cluster, find their vitality in the Boomi Atom – a meticulously engineered, lightweight runtime engine in Java. This Atom serves as the powerhouse, executing our orchestrated processes seamlessly, ensuring the symphony plays harmoniously, and the integration framework functions with optimal efficiency.

However, in the grand performance of Boomi processes, challenges may arise. When job executions exceed expected durations or display an unexpected surge in resource consumption, signaling heightened CPU or RAM usage, or encounter unforeseen failures – these occurrences unveil themselves as discernible symptoms of an underlying performance-related issue.

Boomi AtomSphere Environment

Now, for our performance testing endeavors, I embark on setting up a singular atom on my M2 MacBook Pro 2022, running the sleek macOS Monterrey 12.4. The goal is to simulate common performance issues akin to a production environment and use yCrash in aiding triage, troubleshooting, and ultimately arriving at a resolution.

To lay the groundwork for our performance testing theater, our initial act involves loading the buggyApp into Boomi. Employing the adept ant scripts within the buggyApp Git repository, I compile a JAR file. The subsequent act involves uploading this JAR to the Developer Libraries section within Boomi. Crafting a bespoke library component called a custom library.

Within the newly created component, I reference the uploaded JAR file within the Developer Libraries section, culminating in its deployment to my local Atom. With these preparations, our stage is set for a performance-testing symphony, where we’ll explore and address common bottlenecks with the aid of yCrash and buggyApp. 

yCrash Environment

Conversely, yCrash needs an agent setup on the Macbook that is running the Boomi atom daemon. During the test the yCrash agent needs to be running. Also, ensure that the yCrash agent yaml configuration uses the Boomi JRE that comes with the Boomi Atom installation. Follow the agent setup installation instruction for the yCrash agent at: https://docs.ycrash.io/

A Word On Thread Deadlock

A thread deadlock in Java occurs when two or more threads are blocked forever, each waiting for the other to release a lock. This situation can lead to a standstill, where the threads are unable to make progress. A common scenario for a thread deadlock involves two or more threads and two or more locks.

Thread deadlocks mainly occur due to the reasons described below:

Reason	Description
Circular Wait	This occurs when two or more threads wait for each other to release resources in a circular chain. For example, Thread 1 waits for a resource held by Thread 2, and Thread 2 waits for a resource held by Thread 1.
No Preemption	In certain situations, the operating system or the Java Virtual Machine (JVM) may not forcefully preempt a thread holding a resource. If a thread doesn’t voluntarily release a resource, and there is no preemption, other threads waiting for that resource may lead to a deadlock.
Hold and Wait	A thread holds a resource and waits for another resource, but it still holds the original resource. This can create a scenario where threads are waiting indefinitely for resources held by each other.
Mutual Exclusion	Resources that are not designed to be shared by multiple threads simultaneously can lead to deadlocks if multiple threads attempt to acquire them concurrently.
Lack of Proper Lock Ordering	If different threads acquire multiple locks in a different order, it can lead to deadlocks. If one thread acquires Lock A and then Lock B, and another thread acquires Lock B and then Lock A, a deadlock may occur if they try to acquire these locks simultaneously.
Resource Depletion	In scenarios where a finite pool of resources is available, improper allocation and deallocation of resources can lead to deadlocks. If threads do not release resources properly, the pool may become exhausted, causing other threads to wait indefinitely.
Inadequate Synchronization	If synchronization is not implemented properly, and shared resources are accessed without proper locks, it can lead to unpredictable behavior and potential deadlocks.

In order to simulate a deadlock scenario within Dell Boomi, we will create a simple process that has 3 shapes/steps: Start shape (no other significance then the start of the process), the data process shape which invokes a custom groovy script which invokes the buggyApp, and the stop shape which terminates the process without exception. The custom groovy script for the process is below, it invokes the Deadlock Demo class within the buggyApp.

import java.util.Properties;

import java.io.InputStream;

import com.buggyapp.deadlock.DeadLockDemo;



for( int i = 0; i < dataContext.getDataCount(); i++ ) {

    InputStream is = dataContext.getStream(i);

    Properties props = dataContext.getProperties(i);



    DeadLockDemo.start()



    dataContext.storeStream(is, props);

}

Boomi Process Execution

After the job has been saved, deploy it to your local atom. Then head over to process reporting and execute the deployed job.

Boomi Initial Diagnostics

After running the job, I tailed the “container logs” and noticed the thread deadlock detector that runs within the Boomi Atom was triggered:

Jan 3, 2024 6:55:42 PM EST WARNING [com.boomi.container.config.deadlock.DeadlockHandler updateDeadlockCyclesCache] New potential deadlock found: DeadlockCycle{_deadlockedThreads=[UniqueThreadInfo{_threadName='Thread-3', _threadId=190, _lockOwnerId=191, _lockOwnerName='Thread-4', _lockName='java.lang.Class@77c2b773', _blockedCount=2, _waitedCount=1, _stacktraceElement='com.buggyapp.deadlock.HotObject.method2(HotObject.java:9)'}, UniqueThreadInfo{_threadName='Thread-4', _threadId=191, _lockOwnerId=190, _lockOwnerName='Thread-3', _lockName='java.lang.Class@3a476c78', _blockedCount=1, _waitedCount=1, _stacktraceElement='com.buggyapp.deadlock.CoolObject.method1(CoolObject.java:9)'}], _initialTimestamp=Wed Jan 03 18:55:42 EST 2024}

yCrash – Diagnostics

I waited a bit, and jumped over to yCrash, immediately I found the incident captured:

Within the issues in the application section I could see a message ‘The application is suffering from deadlock. Here are the threads that are causing the deadlock’. I clicked on the hyperlink and was transported to a thread dump report that mentioned the same.

Clicking on it further, I was able to get details of the deadlocked thread states.

In summary, yCrash can monitor and alert on critical performance bottlenecks like deadlocked threads. It remains a handy and graphically inclined tool to monitor applications.