url_response probe error profile is delayed because it is already running

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

• Periodically we are getting an alarm from url_response probe such as:

• Profile <profileName> is delayed because it is already running.

• We have the interval set to 300 and the delay to 30 seconds. 

• Why are we getting this error?

Environment

• Version: Any
• Component: url_response

Cause

This delayed alarm message can occur when a profile is still running or when no thread is available for profile execution.

The formula for calculating the max time for a profile is:

<Timeout> x <Number of Retries> x <Number of Samples> = <Total Time a profile can take>

Resolution

It is expected that the profile interval should be GREATER THAN the total time it takes a profile to finish.

The example where you would get this error

5 Samples X 3 Retries X 30 Second Timeout = 450 seconds.

If you have an interval set for 300 then you would get this alarm if the profile is unable to complete.

Make sure the interval for the profile is less than the total time a profile needs to fail if you do not want to see this alarm.

For example:

In the url_response probe you can use raw configure mode and try doubling the max_threads.

Then deactivate the probe.

Wait for the port and PID to drop.

Then activate, and test again.

Additional Information

• If increasing the url_response probe max_threads setting doesn't resolve the issue, double-check the profile configuration. In one case where the url_response probe was throwing these alarms for several profile names:

  • Profile <profile_name> is delayed because it is already running and throwing a communication error, e.g., 

  • Unable to access the '/<UIM_domain>/<UIM_hub>/<UIM_robot>/url_response' probe communication error(80040402)'

• it turned out the the wrong IP address was configured for the url in the profile(s) and once it was corrected, resolved the alarms and communication error.

Optionally, if you currently don't have the time to find the root cause or solution, you can always adjust the severity and/or setup a nas AO rule to close the alarms or a nas preprocessing rule to exclude (delete) the alarms until you have more time to test and discover the root cause.