Ldap connector DAP_TIMELIMIT_EXCEEDED
cneberg at gmail.com
Mon Apr 22 12:31:07 EDT 2019
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.
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.
> 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
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users