url_response: "no available threads" alarms
The url_response log indicates that it is running out of threads and you may see errors in the log or alarms indicating this situation such as:
Oct 27 08:59:32:345  url_response: thread pool exhausted
Oct 27 08:59:32:346  url_response: thrRun - no available threads
url_response any version
url_response probe runs out of threads.
The url_response will at startup allocate memory for and start the configured number of minimum threads. Then it will try to execute all the active profiles. If the number of active profiles are higher than the number of available threads you will get the threads alarms or errors in the log.
After the third attempt to execute a profile and no thread is available for this one (1) new thread will be started unless this exceeds the configured number of maximum threads. The profiles that are not executed because there are no threads available for them will be delayed for 20 seconds and then another attempt to execute them will be made.
The probe is by default configured to limit the number of concurrent profiles to 100. This means that more profiles can be defined, but then the profiles will be checked after each other so that this can potentially lead to profiles not being executed at the exact scheduled time. An alarm will be issued on this situation.
The limit can be modified with the 'max_threads' setting in the configuration file. Be aware that you will need to check the resource usage of the probe when doing so to make sure not to run into machine-dependant limitations for memory, threads or connections. The probe initially allocates 'min_threads' for profile execution. If there are more profiles defined than this, the probe may gradually increase the number of threads. As I mentioned, profiles that not immediately executed are allocated a thread are rescheduled 20 seconds later. You can configure the min_threads and max_threads options via Raw Configuration for the probe by selecting the probe and holding down the SHIFT key, Rt-Click and select Raw Configure...
Here is some benchmark information from R&D for url_response v3.63 or higher - we were able to run the url_response probe v3.63 with 370 active profiles on a Windows physical machine (CPU: 2 GHz, RAM: 1 GB). We have not observed delayed alarms for profiles with the following probe configuration:
check 'interval': set to '300' seconds for all profiles