[python-ldap] ldap.OPT_DESC, async ops and paged search controls

[Mark R Bannister]

On 22/01/2015 15:16, Michael Ströder wrote:
> Mark R Bannister wrote:
>> On 21/01/2015 09:16, Michael Ströder wrote:
>>> Mark R Bannister wrote:
>>>> I've been using the new ldap.OPT_DESC feature introduced in python-ldap 2.4.17
>>>> and have a question concerning the use of it with asynchronous search
>>>> operations and paged search controls.
>>> Never used that myself.
>>>
>>> Why are you using paging? This only makes sense if you want to retrieve more
>>> than 1000 entries from MS AD.
>> I've tested this now without paged search controls and get the same problem.
> Ok, my local tests show the same results (openSUSE Linux 13.2, OpenLDAP RE24
> from git, python-ldap 2.4.19). And ldap.resiter is not really usable for
> msgid=ldap.RES_ANY.
>
> I vaguely remember having seen this many years ago. Because at that time I had
> rewritten LDAPObject.result() to internally poll for results which made the
> process a CPU hog. :-/
>
> So yes, you should take this to openldap-technical mailing list.
> For there you should ideally present C code depmonstrating the issue. ;-)
>
> Ciao, Michael.
>

I had time to play with this some more, and it emerged that if I did this:

result = ldap.result(timeout=0.0001)

(i.e. instead out timeout=0), it behaves much more the way I expected.  
The number of select() calls drops from over 80,000 to about 3,000 and 
testing different values this seemed to be the most optimal setting (on 
the hardware I was testing on anyway).

So this is definitely one for the openldap-technical mailing list. It 
seems that timeout=0 implies that I want one result at a time, when in 
fact I need a way of requesting all the data currently available in 
kernel buffers but without waiting around for new network packets to arrive.

Best regards,
Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20150127/dc56d893/attachment.html>