cneberg cneberg at gmail.com
Fri Apr 12 13:15:01 EDT 2019

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
> 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/20190412/c857d8d6/attachment.html>

More information about the users mailing list