IdP use of LDAP and connection pooling

[Jim Fox]

We use connection pooling for all our accesses to LDAP.  We use TLS, and 
the overhead of starting up a new session on each query seemed excessive 
to me.  Our openldap servers keep the sessions open all day.

The only time I occasionally see a failure is on a test idp that gets 
accessed once every few days.  It sometimes fails to return any 
attributes.  Retry works as normal.

Jim


On Thu, 8 Sep 2011, Cantor, Scott wrote:

> Date: Thu, 8 Sep 2011 11:26:12 -0700
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: "users at shibboleth.net" <users at shibboleth.net>
> Reply-To: Shib Users <users at shibboleth.net>
> Subject: IdP use of LDAP and connection pooling
> 
> Is there any conventional wisdom or experience with the use of connection
> pooling in the IdP data connectors for LDAP, and specifically AD?
>
> We're expanding use of LDAP as a data source, but my expertise lies
> heavily on the RDBMS side and how the pooling behaves there. I did some
> initial playing around adding a connection pool and am seeing what I kind
> of expected, which is constant LDAP connection resets when the pools
> validate when connections are idle.
>
> I'm just wondering these kinds of things:
>
> - are pools necessary to get reasonable performance on highly loaded IdPs?
> - do they handle failed connections reasonably without ever surfacing them
> as actual data connector failures?
> - are there ways to maintain connections and avoid the timeouts from the
> client end?
> - is pool validation even needed, or does it just retry on failures and
> handle things gracefully?
>
> I use LDAP as a secondary source right now, with no pooling yet, and it's
> basically fine, though I don't know the actual load on the AD servers.
> Last thing I want is to add pooling and have it cause failures (which
> poorly implemented RDBMS pools do cause).
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>