[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS#3985 test039 hangs on Windows

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/