This is a multi-part message in MIME format. --------------080809090905040609080207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit
[email protected] wrote: > [email protected] wrote: >> Hi, >> >> At the end, meta_back_op_result() will map inside the error returned by > ldap_modify_ext to LDAP_OTHER, since we don't call it with LDAP_BACK_SENDERR, > nothing is sent. Since the error is not LDAP_UNAVAILABLE there will be no > retries. I think this happens too in add and delete. > > This explanation makes no sense, since meta_back_op_result is being called > with LDAP_BACK_SENDRESULT, which is SENDOK|SENDERR. > > The bug is definitely a problem, I can reproduce it running test036 repeatedly > on my laptop. Typically the test hangs within 5-10 iterations. This patch appears to fix the dropped result msg problem, but I haven't checked yet to see if it's now sending doubled result msgs somewhere else. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------080809090905040609080207 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/servers/slapd/back-meta/conn.c b/servers/slapd/back-meta/conn.c index 7e63fae..ab88028 100644 --- a/servers/slapd/back-meta/conn.c +++ b/servers/slapd/back-meta/conn.c @@ -787,10 +787,12 @@ meta_back_retry( LDAP_BACK_CONN_BINDING_CLEAR( msc ); } } - } + } +#if 0 /* don't send twice */ sendok &= ~LDAP_BACK_SENDERR; +#endif } if ( rc != LDAP_SUCCESS ) { --------------080809090905040609080207--
