RE: Async problems (ITS#2305)

[hyc@highlandsun.com]

The fix in CVS HEAD is to avoid the buffering step. Buffering reads from a
TCP stream doesn't gain anything, and causes problems in other situations as
well.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of tss@iki.fi
> Sent: Sunday, February 16, 2003 8:18 AM
> To: openldap-its@OpenLDAP.org
> Subject: Re: Async problems (ITS#2305)
>
>
> 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.
>