John Gordon wrote: > I'm using the ldap package to connect to an ldap server and run a query. > Very simple code, along these lines: > > con = ldap.initialize(uri) > con.simple_bind_s(user, password) > results = con.search_s(group, ldap.SCOPE_SUBTREE, filter, attrs) > for r in results: > # inspect the results > > I'm experiencing some intermittent failures
What effects do you see? How do you detect a failure? > and I think it's because the > URI I'm connecting to is actually an alias (proxy? load-balancer? I'm not > sure of the right word here) for a pool of servers, one of which is flaky. There are LDAP proxies with load-balancing and network-level load-balancers. What is deployed at your site? What are the LDAP server? > Is there a way to ask the connection object exactly which server I'm > connected to? Since load-balancers typically share a virtual IP you cannot really determine to which server your client is connected. It's up to this system's configuration. You could ask some monitoring entry in the LDAP server itself but this might also be flaky depending how your LDAP session is dispatched to the LDAP servers. You better should talk to the admin of the load-balancer to make sure session stickyness is guaranteed within one LDAP session. Also load-balancers typically works ok for read access. But if your LDAP client applications writes to a pool of dispatched LDAP servers probably configured with multi-master replication you should read and understand the implications in draft-zeilenga-ldup-harmful first. http://tools.ietf.org/draft/draft-zeilenga-ldup-harmful/ If you're implementing a really heavy application you'd better do load-balancing / fail-over within your application. Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
