HI! For simple synchronous operations there is ldap.ldapobject.ReconnectLDAPObject which does automatic re-connect when ldap.SERVER_DOWN is raised within a *operation_s() method (synchronous operations). You could use that as a starting point to implement connecting to another server in a pool with a failover strategy which fits your needs (sometimes depends on network topology).
BTW: You don't have to call ldap.functions._ldap_function_call() yourself. Ciao, Michael. Yeargan, Yancey wrote: > > Hmm.. I do not know enough about the SimpleLDAPObject code. Perhaps a > python-ldap developer can provide more information (but I think they > will recommend that you not use SimpleLDAPObject). Assigning to self may > not work as you expect. I do not think you will be able to replace > the SimpleLDAPObject inside an exception handler. > > Creating a new LDAP connection using the same URIs as the original is > valid logic, but your code will need to keep track of the state of > pending LDAP requests and whether they have completed successfully, > perhaps storing the requests in some sort of local database. The LDAP > API itself does not provide for this sort of complex behavior. The level > of redundancy you seek is not easy. > > Yancey > > > On Mar 29, 2010, at 1:03 PM, Alberto Luengo Cabanillas (Pexego) wrote: > >> Yeargan, Yancey wrote: >>> >>> I think it is as simple as using multiple URL values separated with >>> spaces. For example: >>> >>> ldap.initalize("url1 url2 url3") >>> >>> The underlying LDAP code will automatically try each URL until one >>> succeeds or they all fail. >>> >>> Yancey >>> >> Hi Yeargan. Thanks for the quick reply but that's not exactly the >> problem we're facing. The point that if you initialize url1, url2 and >> url3, with url1 down, the followup queries will be against url2. >> That's a correct behaviour, but if while you're keeping up that >> connection, this url2 server goes down, you'll get an exception, >> instead of trying to reconnect to next available server (url1 or >> url3), supposing, of course, that they have an equivalent structure. >> So, when this happens, we're initializing another LDAPObject with >> remaining URIs this way: >> >> new_object = >> ldap.functions._ldap_function_call(_ldap.initialize,string_uris) >> >> self = new_object (or self._l = new_object?) >> >> , but this still fails, any suggestion? >> >> Greetings. >> >>> >>> On Mar 29, 2010, at 9:41 AM, Alberto Luengo Cabanillas (Pexego) wrote: >>> >>>> Hi all! Me and a workmate are currently working in an approach of >>>> connecting to different LDAP servers (each one is a replica of >>>> another) because of fault tolerancy purposes. >>>> So, first thing we did was modifying the *__init__* method of >>>> SimpleLDAPObject class (ldapobject.py file) adding a new attribute >>>> "pool" which contains the list of servers passed as param in >>>> *initialize* method as a string. So, attribute .*_l *changes to: >>>> self._l = >>>> ldap.functions._ldap_function_call(_ldap.initialize,self._pool[0]) >>>> >>>> Then, in *_ldap_call *we introduced a /while/ loop surrounding all >>>> code with a boolean condition set to False. When *"func"* call fails >>>> raising a "SERVER_DOWN" exception, we remove URI from pool and >>>> create a new ReconnectLDAPObject instance with self._l attribute >>>> pointing to next LDAP URI in pool. >>>> >>>> The problem we're actually facing is that when *func *calls raises a >>>> SERVER_DOWN exception (with, for example, a *search_s* operation) >>>> the code behaviour is correct when URI is wrong, but when LDAP URI >>>> is right the func calls stills raises an exception...Is this because >>>> of what is explained in the beginning of ReconnectLDAPObject class >>>> (that synchronous methods like search_s() automatically tries to >>>> reconnect when LDAP server is down)?. >>>> >>>> Are we pointing in the right direction? >>>> >>>> Thanks a lot in advance. >>>> <ATT00001..c><ATT00002..c> >>> >> > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > > > _______________________________________________ > Python-LDAP-dev mailing list > Python-LDAP-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev -- Michael Ströder Klauprechtstr. 11 Dipl.-Inform. D-76137 Karlsruhe, Germany Tel.: +49 721 8304316 Mobil: +49 170 2391920 E-Mail: mich...@stroeder.com http://www.stroeder.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Python-LDAP-dev mailing list Python-LDAP-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/python-ldap-dev