LDAP data connector timeouts

[Wessel, Keith]

It’s certainly possible it was the GSLB, the AD servers are run by a different group in our organization. So, I’m not sure. Regardless, I’d like the IDP to give up after about 10 seconds instead of waiting around and letting mod_jk time out waiting for a response after 15 seconds. In the unlikely event that this happens again, we’d prefer to let users get the attributes passed back that are available rather than getting stuck. We’re only relying on AD for group memberships at this time which are only used by a couple of applications. No need to make everyone else suffer when this happens.

Keith


From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Randy Wiemer
Sent: Friday, June 28, 2013 10:52 AM
To: Shib Users; Shib Users
Subject: RE: LDAP data connector timeouts

are you sure it was your domain controllers that were slow to respond and not a consequence of the load balancer?

randy

From: Wessel, Keith
Sent: ‎June‎ ‎28‎, ‎2013 ‎10‎:‎14‎ ‎AM
To: users at shibboleth.net<mailto:users at shibboleth.net>
Subject: LDAP data connector timeouts

We had a situation last week when our Active Directory was hanging on queries resulting in a connection timed out rather than just a connection refused. Attributes were still being returned from our IBM LDAP, but not from AD obviously. And because the timeout was longer than our 15 second Apache mod_jk timeout, users were getting a gateway timed out message from Apache instead of getting most of their attributes returned to their SP.

We’re just using a single hostname for AD since it’s a load balanced hostname. I realize we could add additional names, but it appears the entire AD cluster was responding this way, so that wouldn’t have helped.

So, I’m looking at the settings for the LDAP data connector and wondering if the search time limit query option would help in this case. Does that apply to the entire TCP connection, or does that timer just start running after the connection is established and the query sent?

Thanks,
Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130628/4eb181e5/attachment.html