[Date Prev][Date Next]
RE: ldap_search blocks after several hundred consequtive searches without ldap_result being called (ITS#2389)
The client library does not use non-blocking sockets. If something gave you
that impression, it was incorrect. The fact that your backtrace shows the
program is stuck in write() indicates that the underlying network buffers are
full. In this case the library has no choice but to block. The only reason
the send buffer could fill up is because the server has stopped reading your
requests. The only reason the server would stop reading is if it has gotten
stuck trying to send replies back to you. The server's send buffer fills up
because you haven't read any of the replies.
I suppose you've found an interesting Denial-of-Service attack here. Probably
the smart thing for the server to do here is to ignore any incoming requests
on a connection while it has any replies blocked, otherwise a program like
yours could consume huge amounts of resources in queued replies.
First of all, I suggest you change your client to avoid this request pattern.
We'll look into insuring the server doesn't lock up.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of email@example.com
> Full_Name: Rand Wacker
> Version: 2.0.27
> OS: Linux/Solaris 8
> Submission from: (NULL) (184.108.40.206)
> We have a component that under certain conditions will send
> several hundred
> ldap_search() requests to an LDAP server without calling
> ldap_result() in
> between them. I am observing that under these conditions,
> ldap_search() will
> eventually block in a write call at sb_stream_write()
> (sockbuf.c:539). The
> searches are all very small, with a filter of simply
> (mailRoutingAddressfirstname.lastname@example.org) and requesting only one attribute.