RE: OpenLDAP 2.1.17 released

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Alan Sparks [mailto:asparks@doublesparks.net]

> Howard Chu said:
> >
> >>     Fixed slapd request flooding bug (ITS#2389)
> >
> > This change will have particular impact on sendmail queries of LDAP.
> > Read the ITS and the updated slapd.conf(5) manpage for
> > details on the new "conn_max_pending" keyword.
>
> Is there an indication on how this might affect people who also run web
> servers and PAM/NSS stuff?  To what extent was it limited before, if at
> all?  The max of 100 unauth'ed feels low to me, I wonder what the
> indication (syslog?) will be if that limit is crossed...

This change affects a particular situation of an LDAP client that submits
thousands of queries before reading any replies. PAM/NSS etc. don't behave
this way, they always submit a single request and wait for the reply before
doing anything else.  With most clients, no session ever has more than 1
outstanding request so they will not be affected by this change. 100 is
really very lenient, and of course you're free to set it to as high a number
as you need, but in practice a high number of outstanding requests indicates
to me a broken client.

There was no limit before. As reported in the ITS, if a client submitted
enough queries without ever reading the replies, eventually slapd's output
buffer would fill up and slapd would lock up waiting for it to drain. When
the client drops the connection things should free up, but that depends on
the particular operating system and how it treats unread data in a socket
when the connection closes. If the unread data is not discarded by the OS,
then slapd would remain locked up.

Also prior to this change, a single client could monopolize the slapd by
submitting a long string of requests in rapid succession. I.e., slapd would
always read all of its available input on a given socket before moving on to
do something else. If the socket always had data to read, then nothing else
would ever get done. Again, this scenario generally arises with sendmail, and
a result of this behavior is that any other clients would get poor or no
service. With this change, slapd will always read a limited number of
requests from any given session and then move on to the next. This new
behavior gives a noticable improvement in responsiveness under heavy load.

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