LDAP connections Retry

[Niva Agmon]

Thanks Daniel.
We’ll be going in the direction you’re pointing – increase response time carefully and see what can be done on the LDAP side.

On a related note - It looks like we might be walking away from using the load balancer, so I tried setting connectionStrategy=round_robin, but that didn’t seem to work – was always hitting the first node in the list.
Changed it to connectionStrategy=random and now I can see authentication happening on both nodes alternately, and failover working as expected.

Thanks again!
Niva


From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Daniel Fisher
Sent: Friday, December 22, 2017 11:23 AM
To: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: Re: LDAP connections Retry

On Thu, Dec 21, 2017 at 10:45 PM, Niva Agmon <nagmon at temple.edu<mailto:nagmon at temple.edu>> wrote:
Dec 20 22:50:37 xxxx.temple.edu<http://xxxx.temple.edu> #011Caused by: org.ldaptive.LdapException: javax.naming.NamingException: LDAP response read timed out, timeout used:3000ms.

You can control the response timeout, so increasing it may be a reasonable option for you.


b.       Creating new connections – fails partially - just realized that it works if I use ssl (port 636), but fails if we use starttls –

The reason it's failing is that startTLS is an extended operation performed on the connection and your LDAP is taking too long to perform operations.
There's not much the IDP can do if your LDAP cannot keep up.
Increasing the response timeout may get the data back to the client eventually, but the wait time could be unacceptable.
I'd recommend that you look at tuning your LDAP before tweaking the IDP configuration.

--Daniel Fisher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171222/2edabca2/attachment.html>