Re: OpenLDAP 2.1.22 and "deferring operation" error message

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 01:07 AM 2/12/2004, Aleksander Adamowski wrote:
>Kurt D. Zeilenga wrote:
>>>slapd[12273]: deferring operation because of conn->c_conn_state == SLAP_C_BINDING
>>>So it seems that the operations are deferred because the connection is in the process of binding. Any ideas how can this be remedied?
>>It's not a problem that needs remedying per say.  That is,
>>it's quite normal for the server to defer the operation
>>where the client didn't wait for the bind to complete.

Note that the slapd should restart this operation immediately
after the bind completes.

>>Guess you could change the client so that it waits, but we
>>don't (for simple bind) require that.
>The client in my case is the Courier MTA (its 2 daemons, actually:
>authldap and ldapaliasd).
>I've grepped through its source and it only uses synchronous binds
>(ldap_simple_bind_s() function).
>It calls it  only in 3 places across the whole source code. And it
>always does this on new connections - seems there's no connection
>sharing between threads/processes.

You might use a network analyzer to see what's really happening on the
wire.

>Am I thinking correctly that those operations should never be deferred
>because the synchronous bind always waits for completion?

Normally (in a single threaded, non-shared application), yes.

It could be (I haven't looked at this slapd code in a while) that their
is a race to check.   That is, the client is proceeding after the bind
response faster than slapd can clear the binding state flag.  Again,
that should be no big deal, the client's next request just gets deferred
until slapd catches up.

Kurt