IBM Security QRadar SOAR

Hi SOAR Community,

We've recently become aware of an issue with SOAR apps where the value set for num_workers is not reflected in the number of timers that you can set at one time. num_workers is a setting that can be set in the [resilient] section of the app.config file. This setting governs the number of worker threads that the app can dispatch at any given time to process messages from SOAR. What we've discovered recently is that this setting is bottle-necked by a separate setting called stomp_prefetch_limit. This setting is also set in the same section of the app.config file and governs the number of messages that the STOMP client will read off of the queue before it considers itself "full" and waits for those messages to complete.

This is an issue for any app administrator that wishes to dispatch more functions at the same time by leveraging the num_workers settings. When using the num_workers setting, be sure that the stomp_prefetch_limit setting is set to the same value. This is especially important for the Timer app and any other apps with long running functions that require many workers to run in parallel. For the Timer app we generally recommend setting the number of workers and prefetch limit to the maximum possible. See the Timer app's documentation which has updated details on this issue as of March 2024.

As of v51.0.1.0.695, the maximum setting for num_workers is 500 and stomp_prefetch_limit has no bounds. We plan to investigate whether the worker limit can be increased given the relatively light weight nature of most functions that we deploy. Keep an eye on the SOAR Python libraries release notes which are posted here every release for details on updated limits for this setting.