Ldap connector DAP_TIMELIMIT_EXCEEDED

[cneberg]

The failoverdata connector doesn’t seem to help when the ldap server side
timesout maybe because it doesn’t treat it as a error?

Worse yet - I had enabled a result cache in ldap to lessen any load on the
ldap servers and I suspect that the result cache is caching that the user
isn’t in ldap - so they can’t log in from any browser until the cache
expires - this just a guess based on how few ldap queries I’m seeing in the
logs while a user tries across different browsers.

Christopher

On Fri, Apr 12, 2019 at 12:15 PM cneberg <cneberg at gmail.com> wrote:

> Thank you I’ll try a failover connector.  Thank you also for opening an
> issue to decide what behavior is expected on an error.  I don’t own the
> upstream ldap server I use so any enhancements in the idp to lessen the
> effect of upstream issues is appreciated.
>
> Topher
>
>
>
> On Thu, Apr 11, 2019 at 1:43 PM Daniel Fisher <dfisher at vt.edu> wrote:
>
>> On Wed, Apr 10, 2019 at 11:16 AM cneberg <cneberg at gmail.com> wrote:
>>
>>> >If you're seeing timeLimitExceeded then you're likely processing an
>>> empty result set. Check your logs to confirm.
>>>
>>> Yes, I believe that is what is happening.    Since there was an error
>>> I'd like it to retry, preferably to a different ldap server in the
>>> list and if that fails -  return an error to the user.      If there
>>> is an ldap error I don't think it makes sense to treat it the same as
>>> the user not being in ldap.
>>>
>>
>> A time limit exceeded result is not treated as an error on a search
>> operation. Whatever results are returned are processed. I'll file an issue
>> to look at that behavior. Whether or not it's an "error", it's probably
>> violating the principal of least surprise.
>>
>> Retries are built around connection issues. The connection is closed,
>> reopened, and the operation is tried again. In the scenario you've
>> described you may reconnect to the "overburdened" directory again. There's
>> no strategy for guaranteeing it will try a specific host. I think
>> specifying a Failover connector is your best bet. That and fixing the
>> problematic directory.
>>
>> --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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190422/4fd55e4e/attachment.html>