defect

[Leif Hedstrom]

Well, I don't know if this is the same problem I had with Python LDAP v1.x,
we haven't tested v2.x yet. But, the result() function in Python LDAP can go
into a very tight poll loop, with extreme effects if the Python process is
running on the same machines as the LDAP server. Python will almost
completely starve slapd for any CPU time ...

Adding a short sleep() in the polling loop of ldapobject.result() helps, a
lot. Like

    while all:
      while ldap_result[0] is None:
        if (timeout>=0) and (time.time()-start_time>timeout):
          self._ldap_call(self._l.abandon,msgid)
          raise _ldap.TIMELIMIT_EXCEEDED(
            "LDAP time limit (%d secs) exceeded." % (timeout)
          )
        ldap_result = self._ldap_call(self._l.result,msgid,0,0)
        if ldap_result[0] is None:
          time.sleep(.01)
      if ldap_result[1] is None:
        break

(note the time.sleep() call if there was no result). Alternatively, adding
an (arbitrarily) long timeout in the call to ldap_result() also accomplishes
the same thing, like:

     ldap_result = self._ldap_call(self._l.result,msgid,0,15 * 60)

I haven't dug deep into this problem yet, to figure out if this is an
OpenLDAP library problem, or a Python LDAP problem. I just know that
preventing ldapobject.result() from going into the tight polling loop solved
our problems. :-)

Cheers,

-- Leif