Re: Async problems (ITS#2305)

[tss@iki.fi]

No, timing wasn't the reason it worked. The code path goes like this:

- poll() says there's incoming data
- libldap reads multiple replies into buffer (bind() reply + reply to
first request)
- libldap processes only the bind() reply, leaving the reply to first
request in the buffer (because it sees timeout)
- we're stuck: we're waiting for the reply, but since it's already read
to buffer, poll() says there's no more data and we never knew it came.
If I called ldap_result() again it would get processed, but that would
mean I'd have to call it twice every time just to make sure it didn't
miss one reply.

My patch made it process all replies in the buffer, no matter if any
timeouts occured. I think that's the way it should be done in any case.

CVS HEAD doesn't compile right now with me (incompatible berkeley db),
but I didn't notice any fixes to above..

On Sat, 2003-02-15 at 00:39, Kurt D. Zeilenga wrote:
> Your patch is not believed to significantly alter the behavior
> of the library.  It may have only worked because it changed
> the timing of calls.  Please test a clean version of OpenLDAP,
> preferably HEAD, OPENLDAP_REL_ENG_2_1, or at a minimum, the
> current "stable" release (2.1.12).  If you get a hang, please
> then use a debugger to obtain a stack back trace (gdb bt) so
> that we can see exactly where it hanging.
> 
> At 10:50 PM 2/7/2003, tss@iki.fi wrote:
> >Full_Name: Timo Sirainen
> >Version: 2.0.27
> >OS: Linux
> >URL: ftp://ftp.openldap.org/incoming/timo-sirainen-030208.patch
> >Submission from: (NULL) (213.185.36.189)
> >
> >
> >(Same as my mail to openldap-devel, which seemed to get ignored)
> >
> >ldap_result() doesn't seem to behave very nicely when trying to use it
> >asynchronously. I call it whenever poll() says there's new data in ldap
> >fd, but if timeout is anything less than 1 second, it doesn't work
> >right. And 1 second timeout is too much since my process is doing other
> >things as well.
> >
> >It looks like the problem is that first time when calling it,
> >try_read1msg() finds a reply to non-search request and returns -2
> >(result.c line 695). So, ldap_request() then checks if it's spent enough
> >time, with <1sec timeout it has and doesn't try to read the data until
> >later when new data comes. Then it gets a reply to previous request and
> >the new one is stuck..
> >
> >I guess the real problem is that both of the requests are read into
> >buffer, but only one of them is actually handled. So, how about always
> >parsing the requests until valid one is found or buffer is empty?
> >Included patch seems to work with me.