LDAP recovery?

[cneberg]

>A response timeout does not cause a retry, it's handled as an error as is typically an indication that your query is missing an index.

Do you mean it may be missing an index in ldap on one of the queried
attributes?      Could you add an option to retry on ldap error
including client timeout and server side errors?    Since the query is
hardcoded in the configs I had assumed the query itself usually works
and therefore the error is likely transient ie. network, or in my case
an overloaded backend ldap server - in which case recoverable on a
retry.

I originally thought connectionStrategy of  ACTIVE_PASSIVE was meant
to fail over like this.  But I guess the docs didn't mean per request
failures and implied a more complete failure.

"ACTIVE_PASSIVE (default value) - Indicates that the first LDAP URL
will be used for every request unless it fails and then the next LDAP
URL will be used."

On Tue, Apr 9, 2019 at 10:04 PM Daniel Fisher <dfisher at vt.edu> wrote:
>
> On Tue, Apr 9, 2019 at 3:10 PM Paul B. Henson <henson at cpp.edu> wrote:
>>
>> I don't remember seeing these before in the same scenario. It looks like when this occurs the idp simply fails the LDAP query and presumably whatever login transaction was attempted at that time? I would expect on an LDAP failure for it to try to reconnect to the LDAP server and reissue the query, which would work, as the reconnection would hit a different backend service to the load balancer that wasn't bound. I haven't received any complaints, but presumably people would just retry once or twice and it would work so we might not get any. In my interpreting this correctly as a failure, and if so, is there any way to get it to not fail and retry instead?
>
>
> Your load balancer should send resets to all client connections in this scenario, that will allow the active query to retry properly. A response timeout does not cause a retry, it's handled as an error as is typically an indication that your query is missing an index.
>
> --Daniel Fisher
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net