Re: [SPAM] Re: CONNECTING FROM A SERVERS POOL

[Michael S. <mi...@st...>]

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&#174; 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
> Pyt...@li...
> 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: mi...@st...    http://www.stroeder.com