- UNIFYBroker Forum
-
Questions
Identity Broker 5.2 LDAP interface timeout when another connector is running
In my solution, when one of my connectors is running I see timeouts when performing LDAP queries against Identity Broker containers.
Answer
The LDAP query code (summarised) is shown below. Default LDAP query timeout seems to be around 15 seconds or so.
$null = [System.Reflection.Assembly]::LoadWithPartialName("System.DirectoryServices.Protocols")
$broker = New-Object System.DirectoryServices.Protocols.LdapConnection $brokerURL
$broker.AuthType = [System.DirectoryServices.Protocols.AuthType]::Basic
$creds = New-Object "System.Net.NetworkCredential" -ArgumentList $brokerUsername, (ConvertTo-SecureString -String $brokerPassword -AsPlainText -Force)
$broker.Bind($creds)
$baseDN = "OU=$adapterOU,DC=IdentityBroker"
$scope = [System.DirectoryServices.Protocols.SearchScope]::Subtree
$query = New-Object System.DirectoryServices.Protocols.SearchRequest -ArgumentList $baseDN, $objectFilter, $scope, $null
Hi Adrian,
Connector operations require taking a writer lock out on the database, which will block other operations from reading at the same time, so the timeouts are to be expected. What is the impact of this? Once the connector operation finishes, your queries should complete normally - will your solution retry timed out queries? Are you able to schedule the operations such that they don't occur simultaneously?
My solution is a simple powershell script invoked from a Broker powershell connector, so it won't retry and the Import will fail (and presumably log an error in Broker).
However when MIM connects to Identity Broker, it uses the same LDAP interface, so that would causes the MIM import to fail as well and report a connection error.
That seems like a significant issue to me - having Identity Broker unavailable for any queries while a connector is running is a poor situation. Can I confirm that you're effectively saying that practically speaking, Identity Broker is single-threaded?! What is the situation if the connector takes a long time to complete - is it unavailable for requests for the majority of that time?
Where there is only one scheduler (e.g. Event Broker) it should generally be possible to ensure that that scheduler only invokes one Identity Broker operation at a time.
My solution is a simple powershell script invoked from a Broker powershell connector, so it won't retry and the Import will fail (and presumably log an error in Broker).
You could consider adding retry logic to the PowerShell script. See this blog post as an example.
However when MIM connects to Identity Broker, it uses the same LDAP interface, so that would causes the MIM import to fail as well and report a connection error.
That seems like a significant issue to me - having Identity Broker unavailable for any queries while a connector is running is a poor situation. Can I confirm that you're effectively saying that practically speaking, Identity Broker is single-threaded?! What is the situation if the connector takes a long time to complete - is it unavailable for requests for the majority of that time?
The connector operations are performed in pages, and the lock should only be held for a single page, giving other operations a chance to run between pages. LDAP queries are similarly performed in pages, meaning the sequence of pages might end up being interleaved. Other factors such as the health of the database and hardware specifications of the server can also impact the duration that database locks are held. Please see Identity Broker Database Recommendations.
I agree that failed imports are not ideal, but solutions need to be resilient to failing operations for a number of other reasons as well. That said, we have work in the pipeline to improve database performance and context isolation to improve this situation.
Customer support service by UserEcho
You could consider adding retry logic to the PowerShell script. See this blog post as an example.
The connector operations are performed in pages, and the lock should only be held for a single page, giving other operations a chance to run between pages. LDAP queries are similarly performed in pages, meaning the sequence of pages might end up being interleaved. Other factors such as the health of the database and hardware specifications of the server can also impact the duration that database locks are held. Please see Identity Broker Database Recommendations.
I agree that failed imports are not ideal, but solutions need to be resilient to failing operations for a number of other reasons as well. That said, we have work in the pipeline to improve database performance and context isolation to improve this situation.