LDAP "Test Connection" and "Browse" features can timeout due to running at Standard MID Server priority for the probes. The timeout is 55 seconds, which is not always something even a healthy MID Server can respond within.
In the case of LDAP Connection Tester, the LDAP server may be marked as Down and trigger false alerts. The LDAP Monitor may show Connection Status as Not Connected, when there isn't actually a problem connecting at all.
e.g. ldap://x.x.x.x:389/ Did not get a response from the MID server after waiting for 55 seconds
The Browse feature may be too slow or become unusable.
This is a common occurrence when a MID Server is highly utilized, when it is likely that many other of the lowest Standard priority (ecc_queue.priority=2(the default)) jobs are queued for the same MID Server, such as during a Discovery run or other heavy Integrations usage or backlog. Queued jobs will probably run within minutes, and that is not a problem with the MID Server, as you do expect peaks and troughs in load, and by its nature it is an Asynchronous system. Jobs that need to respond quickly should be set to run at the higher Expedited (1) priority.
Steps to Reproduce
- Install LDAP and configure it to work through a MID Server
- Identify a time when the MID Server will expect to have a backlog of non-urgent Standard priority jobs, or engineer a situation like that (perhaps just after a Shazzam sensor has triggered hundreds of Classify probe outputs at the same time, which is perfectly normal)
- Open the LDAP Server form, and click Test Connection. The Page will hang for 55s and then give error like: e.g.
ldap://x.x.x.x:389/ Did not get a response from the MID server after waiting for 55 seconds
- Look in the ecc_queue for the LDAPConnectionTesterProbe topic ecc_queue output record, and you will see it still in Ready or Processing state, and it will eventually successfully be Processed, however the LDAP form has given up waiting by then. However all previous outputs in ready state will have to run before its turn in the queue.
- Also note that the Priority field of that output record is set to the default priority=2 - Standard.
This issue is under review.
The error may be a false positive due to this issue. A simple test to confirm that the LDAP test timed out in the past, but the MID Server did eventually return a positive result is to check for ECC Queue input records:
- Open the ECC Queue, and filter on:
- Topic = LDAPConnectionTesterProbe
- Queue = Input
- State = Ready
If the State is Processed, it means the response came back within 55s and was processed within the timeout. If state stays as Ready, it means it gave up waiting and never processed it. Inspecting the payload of the ECC Queue input will provide the true result of the LDAP test.
Dedicating a MID Server for the LDAP Integrations is one workaround. This would avoid other features sharing the MID Server, which could potentially slow down the processing of these LDAP jobs.
If a MID Server needs to be shared with other features, consider adding a before insert Business Rule to change the priority while the ECC Queue records are being inserted:
- Insert a new Business Rule with the following values:
- Name: ServiceNow PRB1331240 LDAP Priority
- Table: ECC Queue [ecc_queue]
- When to run:
- When: Before
- Insert: Ticked
- Condition Filter:
- Queue IS Output
- AND Priority IS Standard
- AND Topic IS:
- OR LDAPConnectionTesterProbe
- OR LDAPDetailProbe
- Set field values: Priority TO Expedited
Note: Do not set anything to "Interactive" Priority. That should be reserved if possible only for MID Server housekeeping jobs, such as HeartbeatProbe. "Expedited" is enough to raise it above the "Standard" priority.
Related Problem: PRB1331240