At 11:06 AM 10/7/2005, Howard Chu wrote: >There appears to be more than one failure condition here. Aside from the >extremely slow execution when the test succeeds, I still see infinite hangs >occurring. > >My latest run from last night is still running now, and slapd.3.log shows >there is a msgID in Request Completed state that has been on the queue for the >past 12 hours with no other activity occurring on any of the clients or >servers. It appears that someone has lost track of this request after chasing >a referral unsuccessfully. > >I'm finding the lm->lm_chain/lm_chain_tail processing code to be rather >unconvincing here, wondering if it is related to the loss of state.
This could be related to Jong's fast sync search patch. I've cc'ed him for comment. >In particular, the use of lm_chain_tail in ldap_parse_result makes little >sense. The initial code assumes that the message pointed to by lm_chain_tail >is the first result of interest. Then after that parse is done, the bit about >"Find the next result..." acts as if there may be another result after the >tail. Clearly if we were already on the "tail" message there should not be >anything following it. I believe the use of chain_tail here to optimize the >retrieval of the result message is a bad idea. > >On the other hand, when exactly is it possible for a single request to have >more than one result message? In LDAP, there can be many intermediate responses (as in a search entries, search references, and extended intermediate responses) to a single request, but only one of those responses contains the final result (as in searchResultDone). >Googling for LDAP_MORE_RESULTS_TO_RETURN shows that at least Sun/Netscape >think this can only happen as the result of a SASL Bind request. >But there's nothing in the protocol spec (or LDAPbis drafts) that mentions >this. LDAP_MORE_RESULTS_TO_RETURN is an API error, not a protocol result code, and hence not discussed in protocol specifications. >It appears that this error code has no real application, and "Find the next >result..." is wasted effort. What's really going on here? The API error is used in two places in libldap. One in returning a SASL_CONTINUE condition and in ldap_parse_result() to indicate if more results are in the chain. >-- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/
