1. UNIFYBroker Forum
  2. Bugs
0
Fixed

Clear connector race condition.

Tony Sheehy 12 years ago • updated by anonymous 9 years ago • 5

There is a race condition in Identity Broker that could cause incorrect deletes on adapter delta imports.

Imagine I have done an Import All on a connector which returned 20 changes.

I immediately follow with a clear all operation, which clears the connector and adapter context, as well as any processed changes.

Imagine that 10 changes have not yet been processed (possible with very large change sets).

These changes will then be picked up by the change processor, and registered as changes.

If I follow up with a Delta import from FIM, IDB will calculate these 10 orphaned changes as deletes.

We can handle the currently unprocessed changes by clearing the remaining untouched changes.

For the changes in memory, either the count of changes processed on each cycle will need to be throttled, or a conditional might be added to wrap each cycle, or this potential race condition might just need to be highlighted on the UI/documentation.

Adam van Vliet 12 years ago

Matthew, can you please determine what our options are here, or whether this would be a problem solution wise? I've assigned it to you as you've had previous experience with closing up this style of race condition.

Thanks.

Matthew Clark 12 years ago

Hey Tony,

If the item does not exist in Identity Broker, IdB will of course present the change as a delete.

Possible solutions:

  • Document that automation and change detection operations should be disabled while a clear all operation is running
  • Set a flag at the adapter level to signify a clear all is in progress (only operations that were run manually), and cause imports to fail while this flag is in place. The ChangesAvailable flag should probably also be affected by this flag so as to avoid FIM Event Broker from attempting things while the adapter is in this state.

You actually have a more dangerous race condition during a clear all in that if a full import is run, you will get everything that has been deleted so far being missing from the import file, and only keeping what hasn't been cleared yet (where the changes problem may delete 10 items, a full import may only keep 10).

Please let me know if I've misread the problem you were describing here, and what you think about those solutions.

Tony Sheehy 12 years ago

Hi Matt, I agree with the options you've mentioned. An alternative to a flag on the adapter might be a BaseLineRequired flag on the connector.

Matthew Clark 12 years ago

The only thing there is you still have the same race condition behaviour when a user clears an adapter. If the flag was just at the adapter level for both, then it would address both cases.

Matthew Clark 11 years ago

Adam,

This problem will no longer be relevant in Identity Broker v5 due to the instant reflection to the adapter context. Further processing of changes for deltas should not be swayed by timeliness issues.

Marked as Resolved - Won't Fix.

Customer support service by UserEcho