Ldap connector DAP_TIMELIMIT_EXCEEDED

[cneberg]

>That's what noResultIsError manages. But that didn't fit what you were describing as the error, in my experience anyway. But my LDAP knowledge is rudimentary.

I agree there is a real error being returned so  noResultIsError
shouldn't come into play but it ignores the error and treats as if the
results are empty.  If it would have retried it would likely have
gotten results.

There is another discussion thread -
https://marc.info/?l=shibboleth-users&m=155486549702796&w=2  which is
similar to this one.   Before I expanded
idp.attribute.resolver.LDAP.responseTimeout attribute I was receiving
client side timeouts instead of the server timeout I get now.     I'll
respond to Daniel's last message over there.

On Wed, Apr 10, 2019 at 11:25 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 4/10/19, 11:16 AM, "users on behalf of cneberg" <users-bounces at shibboleth.net on behalf of cneberg at gmail.com> wrote:
>
> > 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.
>
> That's what noResultIsError manages. But that didn't fit what you were describing as the error, in my experience anyway. But my LDAP knowledge is rudimentary.
>
> But it will *not* retry a different server if it gets back no result. Either that's an error or it's not, but it isn't a retryable one. You don't stack LDAP servers that way, you'd use Failover connectors to manage search of discrete data sets.
>
> -- Scott
>
>
> --
> 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