A Boomi Molecule is a powerful runtime option, often chosen by Enterprises for its natural scalability and high availability. There are many ways to customize a Molecule to fit the needs of your integration workload requirements and one of the more interesting–and potentially useful–options is the ability to enable Forked Executions.
While Forked Executions are usually more associated with a Cloud runtime, it is also possible to utilize this feature on a Molecule if enabled on your Boomi account. More than just a configuration option, this setting actually changes Boomi’s entire strategy for executing processes and allocating resources to that work.
Briefly, “Forked Executions” are small, temporary JVMs that are spun up specifically to handle a single process execution and are then shut down when that execution is complete. Once enabled, all process executions will operate within these dynamic, single-purpose JVMs. Further, this option is required if you want to use the “Multi-Process” Flow Control option; without this enabled, a Flow Control shape will default back to Multi-Thread, even if Multi-Process was selected.
Forked Executions are a tool in your toolbox, and like any tool, there are advantages and disadvantages to consider when deciding if this option is right for you.
Advantages
Forked Executions come with significant advantages, including:
Resiliency
Process executions occur in their own dedicated JVMs, meaning they are isolated from each other. Catastrophic problems in one execution cannot interrupt other executions. This makes it a great choice for processing large data volumes, as there is no single point of failure that would halt your ongoing work.
Performance
The ability to process work among parallel JVMs also boosts performance. (Note that it is not quite as big of a performance boost as multi-threading, which does not need to spawn a new JVM to run batches of documents in parallel. Multi-threading is a bit more lightweight and nimble but lacks the other benefits of Forked Executions.)
Footprint
Since your executions will run within temporary JVMs that each get their own memory allocation, the Boomi installation itself doesn’t need to have as much RAM dedicated to it–only enough to handle operational overhead. At the same time, you can also use more of the resources on the machine when needed since these temporary JVMs will spawn in lockstep with your workload. It’s a more “on-demand” model of the Molecule runtime.
Customized Security
You can customize the security policy of your Forked Executions to control their access to the system, to other JVMs, and more.
Disadvantages
The main disadvantages are:
Requires Careful Tuning
All the settings for Forked Executions must be carefully considered to strike a balance between facilitating your workload and keeping overall memory usage within system limits. (See Part 2 for more details.)
Limited Memory Allowed per Execution
The amount of memory each forked execution gets is tightly controlled. You will either need to design your integrations to fit within this Forked JVM memory footprint, to carefully increase the memory allowed to your Forked JVMs, or both.
By default, the limit placed on each Forked Execution is 512 MB. It is not uncommon to increase this value a bit, though any increase will be applied uniformly to all Forked Executions, so changes to this value must not be done lightly. A little bit goes a long way!
Minor Launch Delay when Processes Execute (Which Especially Impacts Listeners)
There will be a slight delay when launching any given Boomi Process execution. This is a small amount of time spent to initially spin up the dedicated JVM.
This launch delay will particularly impact your Listeners, which must also run as Forked Executions when this option is enabled. Listeners are often meant to be light and fast, frequently representing web queries or similar scenarios where the required response times are measured in seconds or less. That being the case, the delay from spinning up the JVM is often undesirable.
On a Cloud, you would have the option to solve this problem by running your listeners on an Atom Worker, while the heavier General Mode executions would run as Forks. However, this isn’t an option on a Molecule, as a Molecule runtime is not able to use Atom Workers. For this reason, if you want the advantages of Forked Executions but don’t want to slow down your Listeners, you have two options:
- You might consider running a second molecule that does not have Forked Executions enabled, specifically to handle your listener executions.
- You might also consider using a Private Cloud.
A simplified comparison showing a standard molecule and a molecule with Forked Executions enabled:
This series will continue in Part 2, where we will discuss the configuration options in more specific detail!
Check out our other Boomi blogs.
For more information, please reach out to us!