python-ldap-dev

CONNECTING FROM A SERVERS POOL

[Alberto L. C. (Pexego) <al...@pe...>]

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.

[SPAM] Re: CONNECTING FROM A SERVERS POOL

[Alberto L. C. (Pexego) <al...@pe...>]

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>
>

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

[Yeargan, Y. <ya...@un...>]

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>

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