In v42 and later, by default, the system does not start block processes automatically after a flow is deployed. Instead, these processes are started only if tasks have been scheduled for the blocks, and they remain active for the amount of time you specify. By allowing the system to initiate and maintain process more selectively, these updates can reduce the total amount of RAM consumed by block processes.
Available settings
If necessary, you can configure the settings described below to change when processes are initiated and how long they remain active:
HS_RUNNABLE_BLOCKS_DISCOVERY_POLICY— determines whether the default policy or the policy from previous versions is used. It has the following valid values:PROCESSING_BLOCKS_FROM_LIVE_FLOWS— the policy used in previous versions. If selected, a process will be started for each block that is referenced by a deployed flow or one of its subflows.PROCESSING_BLOCKS_FROM_WFE_TASKS— the default value. If selected, processes will be started only for blocks that have pending tasks queued for the workflow engine.
HS_ACTIVE_BLOCK_CUTOFF_SECONDS— the number of seconds a block is considered active after it has processed a task. Active block processes are not stopped, even if there are no scheduled tasks for them. Processing a task refreshes the timeout for the block. Therefore, if a block is always processing tasks, its process will never be stopped. The default value for this variable is604800(7 days).
Impact on latency
After enabling this feature, or after upgrading to a version that has this feature enabled by default, there may be increased latency in processing the first few submissions. This latency is due to the processes being initialized after restarting the system. For Docker-based deployments, the latency should be negligible. In Kubernetes-based or SaaS deployments, the latency may last a few minutes, as more time is required for the backing infrastructure to boot.
There should be no added latency after the initial submissions are processed after system restart.
Resolving memory-related issues
If the system is restarted, blocks that were active before the restart will not be started again automatically; only those blocks that have scheduled work will be initialized. As a result, restarting the system could resolve memory-related issues if unnecessary block processes are being run.