RE: connections_timeout_idle

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

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]

> This is where poll(2) interface is a bit better than the
> select(2) interface.   We never switched to the poll(2)
> because of uncertainty with how well operating systems
> deal with poll(2) threading issues.
>
> Anyways, I suggest that we don't stop reading from a write
> blocked descriptor.  Instead we should defer processing of
> operations when the descriptor is write blocked.  And, to
> prevent DoS, we should have some sane limit on the number
> of concurrent requests a client can post (likely a low
> limit for anonymous clients and a higher one for authenticated
> clients).

When said "sane limit" is reached, can we then just throw away incoming
requests? We have no means of imposing flow control on the client. The
current patch stops reading and processing requests when there are
maxthreads/2 outstanding requests on a session. The scenario that raises this
issue submits thousands of requests before the output blocks. The problem
with continuing to read the requests is that we burn a lot of CPU resources,
and in this situation will wind up queueing thousands of requests while
waiting for the output to drain.

The advantage of not reading is that TCP itself will eventually impose flow
control on the client, so we don't burn CPU resources in the meantime.

Without the limit of maxthreads/2, we actually process thousands of requests
before writes get blocked, but by the time the output buffer blocks with the
thousands of replies we've still got a large number of requests executing.

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