- UNIFYNow Forum
-
Bugs
The async result is invalid
Using
- UNIFY FIM Event Broker v3.2.1 RTM x64
The following was written to the Event Broker logs last night:
System.DirectoryServices.Protocols: System.ArgumentException: The async result is invalid. at System.DirectoryServices.Protocols.LdapPartialResultsProcessor.GetPartialResults(LdapPartialAsyncResult asyncResult) at Unify.Product.EventBroker.OpenLDAPListenPlugIn.ResultsCallback(IAsyncResult result)
The error was thrown by the AD listener for the AU.QBE.PRI forest in Production.
Related JIRA issue here.
Answer
- What's the impact of this?
- Is this not expected?
- Is this the first time it has happened?
- Has it succeeded after this error?
- Have you performed any analysis/research/trace on the error?
- This is of minor consequence I imagine - a missed poll is about all the impact would be, resulting in a delay of a few minutes until the next poll.
- I don't know if it is expected or not - that's why I thought I would post it.
- The reason I bothered to post this was that it is the first time I think I've seen this particular error variant of the listener.
- Yes it has succeeded after the error - this is the only occurrence in the current log.
- I have only scanned the logs for other occurrences and there are 5 in the last 5 days (one per day for 3 days and 2 on another day).
If there is a way I can throw something like this up on Voice to flag it as minor interest only (like I did on the JIRA ticket) please let me know. There are about a dozen different errors being logged daily and all I am trying to do is make them visible in an attempt to stabilize the environment. With very limited time and access I can't investigate each one of these now - I am just trying to flag them.
What's the recycle timeout on the operation? It wouldn't happen to be 1 day (the default), would it?
I have a fair idea of what's causing it - the listen operation gets reattached/recycled, and then a result comes in for the previous request. GetPartialResults doesn't like this, so throws the exception. It's safe to ignore.
I'll make the change, and it'll be available in v4.0.
Thanks.
Thanks Adam - retry wait time for the change detection (no listener) shows as '00:01:00' ... where can I find recycle timeout configured?
I see - there is no listener that is configured here because during testing we found this to pick up too many false positives and send the FIM Sync into meltdown. Can this happen on the check operation which IS configured?
That's what this issue is about, see OpenLDAPListenPlugIn in the stack trace.
Yes Adam I can see that in the trace but there is no listener configured on an active Operation List. However there is an inactive one (I deactivated all listeners due to the noise) - yet it still reports being "Live" in its disabled state. I suspect this means that this is the real source of the error and not the active incoming operation list for this AD forest. I had retained all of these operation lists with the intent of turning them back on one day after working out why they were overly "chatty". Why would a listener do anything when the operation list is disabled?
There was a schedule that was reattaching the listen operations. This is now fixed.
Customer support service by UserEcho
What's the recycle timeout on the operation? It wouldn't happen to be 1 day (the default), would it?
I have a fair idea of what's causing it - the listen operation gets reattached/recycled, and then a result comes in for the previous request. GetPartialResults doesn't like this, so throws the exception. It's safe to ignore.
I'll make the change, and it'll be available in v4.0.
Thanks.