Ben Beuchler wrote:
My apologies; I neglected to include an example of the "deferring operation: binding" log entries:
Apr 11 15:14:49 cliff slapd[15355]: conn=1 op=36640 BIND anonymous mech=implicit ssf=0 Apr 11 15:14:49 cliff slapd[15355]: conn=1 op=36640 BIND dn="uid=bbrogan,dc=users,dc=accounts,dc=ldap,dc=mcad,dc=edu" method=128 Apr 11 15:14:49 cliff slapd[15355]: conn=1 op=36640 BIND dn="uid=bbrogan,dc=users,dc=accounts,dc=ldap,dc=mcad,dc=edu" mech=SIMPLE ssf=0 Apr 11 15:14:49 cliff slapd[15355]: conn=1 op=36640 RESULT tag=97 err=0 text= Apr 11 15:14:50 cliff slapd[15355]: connection_input: conn=1 deferring operation: binding Apr 11 15:14:50 cliff slapd[15355]: conn=1 op=36641 BIND anonymous mech=implicit ssf=0 Apr 11 15:14:50 cliff slapd[15355]: conn=1 op=36641 BIND dn="" method=128 Apr 11 15:14:50 cliff slapd[15355]: conn=1 op=36641 RESULT tag=97 err=0 text=
It appears to my untrained eye that the operation both before and after the deferral completed successfully. Any idea what type of client behavior could trigger messages like this?
In this particular case it looks like the client has sent two Bind requests back to back. Possibly without waiting for the result from the first one to arrive. As Ando already explained in a previous response, Binds are required to be fully serialized - when a Bind is active on a connection, no other operations are allowed to run. Furthermore, if non-Bind operations are active on a connection and a Bind is received, all of those active operations are required to be immediately abandoned before the Bind proceeds.
One thing you never mentioned - what version of slapd are you running?
I still don't see any particular failures occurring here. If your client isn't having any problems I wouldn't waste any more time worrying about it. If you feel like rewriting your client, you can follow Ando's advice and use a dedicated connection for Binds and a separate connection for the normal operations, but you'll probably need to use proxy authorization in that case.