Summary
This article provides tips for improving integration process performance.
Question
In the event of having uCMDB to ServiceNow integration running, presently making it capable of pushing CIs over as long as the total amount of CIs+relationships is around less than 1600. Anything higher than that and the process eventually dies with the "Timeout expired. Such error is found in the DDM logs.
The log files (on the Probe or on the ServiceNow side) do not show anything that would indicate a cause to the error, but looking at the message text it seem that the Probe is waiting for a reply from ServiceNow that it fails to receive. Being that this error only occurs when the amount of CIs and their relationships exceeds around 1600, this could have something to do with uCMDB trying to process more data than it can handle in a given amount of time (e.g. due to resources on the server or other reasons).
If tried the settings available in the uCMDB ServiceNow adapter to be such as:
- Max threads
- Max execution time
- Grouping Interval (seconds)
- Max. CIs in group
Varying the values in these has not had any noticeable effect on the performance and has not stopped the integration from leading to an error as described above.
In such scenario, what can it be done to improve the integration process performance?
Answer
An alternative method will be to group the TQLs as when they are set up like that, the Integration Job automatically starts the TQLs in sequence.
To determine where the timeout value is set. You should look at the PushAdapter class inside pushadapter.jar file (located in DataFlowProbe\runtime\probeManager\discoveryResour​ces\Service-Now).
In this class you will noticed that the method "invokeAdHocDDMTask" had following lines which essentially states to throw the DataAccessGeneralException if the task is being processed longer than what is returned by getTimeoutMillis().
while ((!isDone) && (System.currentTimeMillis() - startTime < getTimeoutMillis()));
if (!isDone) {
throw new DataAccessGeneralException("Timeout expired. Check DDM logs to see what's taking so long");
}
The getTimeoutMillis() method on another hand gets its value from the "_props" class instantiated earlier in the PushAdapter class.
The "_props" class, on another hand, is like a HashTable and is just used for storing properties. The class is populated with properties when the HashMap "params" is instantiated; this instantiation happens on the line that looks as follows:
HashMap params = getJobParameters(testConnection, addResult, updateResult, deleteResult);
The "_props" class is populated by multiple lines when the above line is called. For our purposes the one of interest looks as follows:
params.put("timeout", String.valueOf(getTimeoutMillis()));
Above line calls another method named "getTimeoutMillis", which looks like this:
private int getTimeoutMillis() {
return Integer.parseInt(this._props.getProperty("timeout.​seconds", "600")) * 1000;
}
Above method retrieves the property named "timeout.seconds" and sets a timeout value to "600000" milliseconds if nothing else is specified.
By looking at the other retrieved property names , you will noticed that they correspond to what is defined in the OOB "push.properties" file for the ServiceNow Integration.
Therefore, you can add the entry "timeout.seconds=1800" into that "push.properties" file and the integration job got a timeout of 1800 seconds. This will now allowed you to push a larger CI set across without problems.