vt-ldap: connection pooling for SearchDnResolver may enhance login performance

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set up a Shibboleth IdP 2.3.2 with default JAAS login.config for LDAP 
authentication.
2. Do some load testing (i.e. multiple logins per second).
3. Replace the SearchDnResolver with a custom static DN resolver (returning a 
static DN string) and compare the results.

What is the expected output? What do you see instead?
The LDAP connection for searching the user's DN should be reused when lots of 
users log in at the same time. Instead, a new connection (i.e. a costly bind 
operation) to an LDAP server is created each time. Compared to a static DN 
resolver, this does not only impair latency, but also significantly reduces the 
total amount of logins per second in our test setup.

What version of the product are you using? On what operating system
vt-ldap-3.3.4.jar as part of Shibboleth IdP 2.3.2, OpenJDK 6b18, Tomcat 6.0.28, 
Debian GNU/Linux (Squeeze) 64bit.

Please provide any additional information below.
We have configured multiple (replicated) OpenLDAP servers in login.config for 
failover reasons. Already using the pooled LDAP connections in Shibboleth's 
attribute resolver, it turns out that LDAP queries run very fast (about 3ms per 
query), and overall performance is not impaired whether we do just one or even 
five different queries for attribute resolution. It is indeed the LDAP bind 
operations reducing performance, each taking about 50ms and somehow blocking 
the whole Shibboleth IdP.

Original issue reported on code.google.com by Manuel.H...@gmail.com on 2 Aug 2011 at 9:21

[GoogleCodeExporter]

Won't fix for vt-ldap.
Feature added in ldaptive.
JAAS LoginModule available in ldaptive should function as a drop in replacement 
for vt-ldap.

Original comment by dfis...@gmail.com on 21 Mar 2013 at 3:18

• Changed state: WontFix