How do retries work for data connectors?

[Cantor, Scott]

On 3/30/21, 1:52 PM, "users on behalf of Lawlor-Bagcal, Kyle" <users-bounces at shibboleth.net on behalf of kl3020 at tc.columbia.edu> wrote:

>    If we can keep the answers scoped to my example code above that would be helpful for me to understand it
> better.

Sorry, but "read a configuration and tell you what it means" is something I will do for members due to the time it takes, not on list.

There are no "retries" ever at the IdP layer (*) and the noRetryDelay is a window during which a connector is marked for auto-fail and delegates immediately to a FailoverConnector if one exists, and once the delay elapses it will start attempting to resolve again unless it fails and goes back into noRetryDelay. Not having a noRetryDelay just means every request always attempts primary connector resolution. 

Threads inside the resolver never "pause" for anything except for external systems not doing their job fast enough. They're always doing work or waiting for a result from a request from a connector that's networked.

There are many complicating factors such as the result count controls, failFastInitialize, and the propagateResolutionExceptons flag that all interact, and they behave slightly differently in different versions because of bugs that I think are finally fixed and now act the way I would have expected them to.

It is finally the case in 4.1 that if you don't propagate the error from a connector, letting it fail doesn't break anything else and doesn't need a static failover to backstop it. Prior versions had edge cases that really didn't work without that safety net and could cause global resolution failures in some cases.

The noResultIsError and multipleResultsIsError settings (names may be slightly off) will control whether particular LDAP and RDBMS result counts are actually errors or just normal results, but any actual "error" essentially now acts the same way, raising an error or not based on the propagate flag.

-- Scott

(*) I'm sure there's probably some kind of retry semantic going on at the LDAP/RDBMS connection layers but they're not something the IdP knows about directly.