Listener workers
Listener workers offer a dedicated home for listener connections that would otherwise run on an execution worker. When enabled, a listener worker runs as a separate worker JVM, maintaining those connections independently from your execution workers. The software maintaining the connection from the runtime to whatever external service is providing data will managed on an isolated JVM. Once the data is received, the data processing still occurs on an execution worker.
Listener workers are only available for Runtime Clouds, due to their ability to create persistent separate JVMs.
What is a listener worker?
Event-based listener connections run a copy of the connection on each execution worker. When listener connections and execution workers are coupled, scaling one means scaling the other. Growing your execution capacity also multiplies your listener connections, and adding listener capacity requires provisioning more execution workers. This can make concurrency variable and inconsistent.
Listener workers offer an alternative by decoupling listener connections from execution workers.
A listener worker is a dedicated JVM that runs separately from your execution workers. For each listener process, you can choose to run that listener connection on the listener worker, instead of running a copy on each execution worker. Because those connections are isolated to their own worker, you can scale your execution workers and your listener connections independently of each other. Process executions still occur on the execution worker, but the responsibility of maintaining the connection is separated out.
Because they do not run executions, listener workers do not cycle like execution workers do. They are intended to remain active for the life of the cloud.
Review the diagrams below. In the current listener structure, each execution worker runs their own copy of the event lister. And if that listener operation supports running multiple concurrent executions (discussed in more detail below), each execution worker can run those concurrent executions.
When using a listener worker, each listener connection is maintained in a separate worker JVM, leaving the execution workers simply focus on executing processes.
Why use listener workers?
Fine-grained control over listener connections
With listener connections running on execution workers, your concurrent executions and number of listener connections are tied to your number of execution workers. As you scale your cloud (manually or automatically), you necessarily add or remove listener connections, making your connections variable and inconsistent over time. Listener workers give you a clean, predictable model: each listener connection runs on the listener worker, regardless of how many execution workers you have. Concurrent executions across the execution workers are handled by a single Maximum Concurrent Executions (MCE) configuration value. Additionally, you can configure MCE independently per listener process, so a high-throughput listener and a low-throughput listener coexist without one constraining the other.
Scale event-based processing independently
When the event-based connections are run on a listener worker, the cloud also gains the ability to scale up execution workers in response to the number of events. Execution workers cannot create more execution workers, so an overburdened event listener on an execution worker can’t really be responded to. The Listener Worker gives the runtime visibility into event load, and allows it to respond with more or less execution workers.
With listener connections on a dedicated listener worker, you can scale your execution workers up or down based on processing demand without affecting your listener connections, and vice versa. Additionally, the runtime can detect a burst of events on a listener worker and respond to that by scaling up additional execution workers.
Enabling listener workers for your processes
Listener worker configuration is set at the deployed process level, scoped to an environment. This means you can enable it in a test environment first and validate behavior before rolling it out to production.
Currently, users need to have the Listener Worker account feature enabled by their account owner. Enablement for all accounts is planned for a future release.
To enable listener workers via the UI:
As a cloud owner:
- Navigate to Runtime Management, select your cloud, select Properties, then Advanced.
- Set Listen Worker Enabled to true.
- Navigate to Cloud Management, select your cloud, and select Attachment Quotas.
- For each cloud cluster or cloud tenant you want to update, select it and set Listen Workers to 1.
- Observe the other quotas of Listen Worker Maximum Execution Submissions, Listen Worker Maximum Queued Executions, and Listen Worker Queued Execution Timeout, and adjust them as necessary.
As a cloud tenant:
- Navigate to Runtime Management, select your environment, and open Event Listener Configuration.
- Find the listener process you want to configure and open its settings.
- Enable the Listener Worker toggle for that process.
- Set the Maximum Concurrent Executions value (refer to the guidance below before choosing this number).
To enable listener workers via the Platform API:
The EnvironmentProcessConfiguration API lets you manage listener worker configuration programmatically. This is useful if you manage dozens of processes or are an OEM customer automating Boomi configuration for your own customers. Refer to the EnvironmentProcessConfiguration API reference for details.
Note that enabling listener workers on a cloud must currently be done via the platform UI. The ability to enable listener workers on a cloud via API will be delivered in a future release.
Confirm your listener worker is running:
Cloud tenants can check for a running listener worker through the platform Worker UI, or using the Worker API. Listener workers show with the name listener-{ID}.
Considerations when enabling listener workers
Listener Workers are only for event listeners running on clouds
Listener workers apply only to Runtime Clouds; they are not available for basic runtimes or clusters. Currently only non-elastic clouds are supported, elastic support is planned for a future release. A cloud attachment can have at most one listener worker.
Only event listener processes can run on a listener worker; legacy listeners will continue to run on the node.
Listener worker configuration is per process and per environment
Listener worker configuration lives at the deployed process level, the intersection of a process and an environment. If you have the same process deployed to three environments, you need to configure listener workers for each one separately. Changes to one environment's settings do not propagate to others. However those same changes will be propagated to all cloud runtimes in that environment. Other runtime types which do not support listener workers will not be affected
Some connectors have their own concurrency configuration
Some listener operations allow users to configure a number of concurrent listener executions. This is a common pattern mimicked across listeners, however it is not part of the connector SDK, and is not enforced by Boomi. Each connector developer may handle concurrency differently.
Previously this meant your concurrent executions were multiplied by your execution workers. If your connector allowed four concurrent process executions and you were running five execution workers, you could have 20 concurrent executions running. With a listener worker, the Max Concurrent Executions is exactly the maximum number of executions for that process that can run across the cluster, regardless of how many execution workers are running.
Note, this can lead to complex interactions with the connector value. If the connector configures more concurrent executions than the listener worker will allow, those extra executions will be rejected by the listener worker. On the other hand if the listener worker value is configured much higher than the connector value, you may be limited by the connector's configuration and not leverage the capacity of your listener worker. Be sure to check your connector configuration for each deployed process and adjust as necessary. We recommend that the concurrent executions configured in the listener worker matches or exceeds the value configured in the connector, to avoid rejected executions at the listener worker level.
Other relevant configuration values
Cloud owners apply quotas to their tenant listener workers using the Cloud Management U. A future release will add those quotas to the AccountCloudAttachmentProperties API. They can configure:
- Listen Worker Maximum Execution Submissions: How many total concurrent executions the tenant can run across all listener processes
- Listen Worker Maximum Queued Executions: How many execution submissions can be queued while waiting for an available execution worker
- Listen Worker Queued Execution Timeout: How long those executions can remain on the queue
Executions that exceed the queue's length or timeout on the queue will be rejected.
