[Dovecot] Comment from OpenLDAP developer regarding "deferring operations"
I received this response from a member of the OpenLDAP core team when asking about meaning of the deferred operations I was seeing.
Is it possible that this is what I'm seeing, Timo?
-Ben
I'd note that if your client is performing search + bind on the same connection in an asynchronous manner, then the server behavior as per RFC4511 is undefined, since a server is not supposed to be willing to handle operations intermixed with binds until a bind is concluded. That is, any operation can be multiplexed on a single LDAP connection __except__ binds, which must be serialized. A more appropriate client for that type of operations would need to use at least 2 connections, one for searches and one for binds, and the one for binds should take care of either performing synchronous binds, or in any case to wait for response to a bind before performing another. In case of failure (e.g. timeout) while waiting for bind response, the connection should be trashed (see ldap_unbind_ext(3)) and recreated. This is what is done, for example, by slapd-ldap(5).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
I'd note that if your client is performing search + bind on the same connection in an asynchronous manner, then the server behavior as per RFC4511 is undefined, since a server is not supposed to be willing to handle operations intermixed with binds until a bind is concluded. That is, any operation can be multiplexed on a single LDAP connection __except__ binds, which must be serialized.
That's how I thought it was working. But I think I found a bug in there. See if the attached patch fixes it?
I'll apply the patch later this morning and and let you know what I see.
For what it's worth, last night I started dumping traffic between dovecot and openldap. The pattern I see most consistently was this:
-> bind request (anonymous) -> search request <- bind response <- search result
As I understand it, the search request being sent before the result of the bind request is received could trigger the deferrals.
Thanks!
-Ben
On 4/12/07, Timo Sirainen tss@iki.fi wrote:
On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
I'd note that if your client is performing search + bind on the same connection in an asynchronous manner, then the server behavior as per RFC4511 is undefined, since a server is not supposed to be willing to handle operations intermixed with binds until a bind is concluded. That is, any operation can be multiplexed on a single LDAP connection __except__ binds, which must be serialized.
That's how I thought it was working. But I think I found a bug in there. See if the attached patch fixes it?
On 4/12/07, Timo Sirainen tss@iki.fi wrote:
On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
I'd note that if your client is performing search + bind on the same connection in an asynchronous manner, then the server behavior as per RFC4511 is undefined, since a server is not supposed to be willing to handle operations intermixed with binds until a bind is concluded. That is, any operation can be multiplexed on a single LDAP connection __except__ binds, which must be serialized.
That's how I thought it was working. But I think I found a bug in there. See if the attached patch fixes it?
It does! Not a single "deferring operation" entry in nearly an hour!
Now to wait and see if this change, Roy's patch, and linking against the new libldap_r can combine to eliminate my intermittent (and frustratingly non-reproducible) auth freezes.
-Ben
participants (2)
-
Ben Beuchler
-
Timo Sirainen