0
Not a bug

IDB Adapter Delta Import still processing after an Operation Timeout from an MA.

Richard Green 2 years ago in Identity Broker for Microsoft Identity Manager • updated by Adam van Vliet (Product Manager) 2 months ago 2

Hi Gents,


Found an interesting one i believe. We have been seeing the following behavior in the PROD environment out at QDET.


1. A delta import from IDB fails with due to the configured operation timeout being exceeded.

2. After the failure, no subsequent delta imports are triggered via EVB (using the IDB changes plugin as a trigger).

3. Manually triggering a delta import (with an extended timeout setting), clears the issue once the import completes. Further imports are triggered ok via EVB. (Running a Full Import also works here)


I believe the following is occurring:


1. Delta fails due to timeout in FIM.

a. The following is in the windows event log:


The extensible extension returned an unsupported error.

The stack trace is:

"Unify.Product.IdentityBroker.LdapOperationException: Operation timed out.

at Unify.Product.IdentityBroker.LdapConnection.SendRequest(ILdapRequest request)

at Unify.Product.IdentityBroker.LdapConnectionProxy.<SearchRequestPaged>d__6.MoveNext()

at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()

at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()

at System.Linq.Enumerable.<SelectManyIterator>d__14`2.MoveNext()

at Unify.Product.IdentityBroker.ExtensionMethods.Take[TSource](IEnumerator`1 source, Int32 count, IList`1& items)

at Unify.Product.IdentityBroker.ExtensionMethods.<Page>d__0`1.MoveNext()

at Unify.Product.IdentityBroker.ImportProxy.Import(GetImportEntriesRunStep importRunStep)

Forefront Identity Manager 4.1.3627.0"

b. IDB log shows the LDAP connection, followed by a connection aborted error after the timeout.


2. For some reason, the delta operation is not actually terminated within IDB. Thus when EVB tries to check for changes, the operation returns false as it thinks an import is in progress.


This is evidenced by the following. On manually running a delta import from FIM, IDB showed on the adapter that the operation had a duration of 15 hours:


I was able to trace this time back to the exact time when the first delta import operation had timed out:




So essentially it seems that because IDB thinks it's still going, it stops the IDB changes plugin from initiating subsequent operations.


We have a workaround for now - obviously increase timeouts, and run manual operations when needed.

Affected Versions:
Fixed by Version:

Answer

Answer
Planned

Hi Richard,


The issue is that we were constrained to meet the same interface between IdB and EB for the v5.0 development (to avoid spending too much time on an interface that will eventually be redundant). As the interface is bool ChangesAvailable(Guid adapterId), we're unable to tell whether you were successful in importing those changes (as the LDAP endpoint is separate from the adapter) or whether or not multiple clients were checking for changes (still not possible).


As we're now using LDAP, our intention is to meet the specification so that IdB can respond to the same queries that EB issues for the LDAP operations (check changes or listen operation).


Thanks.

Answer
Planned

Hi Richard,


The issue is that we were constrained to meet the same interface between IdB and EB for the v5.0 development (to avoid spending too much time on an interface that will eventually be redundant). As the interface is bool ChangesAvailable(Guid adapterId), we're unable to tell whether you were successful in importing those changes (as the LDAP endpoint is separate from the adapter) or whether or not multiple clients were checking for changes (still not possible).


As we're now using LDAP, our intention is to meet the specification so that IdB can respond to the same queries that EB issues for the LDAP operations (check changes or listen operation).


Thanks.