[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: connections_timeout_idle

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


At 07:30 AM 3/23/2003, Howard Chu wrote:
>>From ITS#2389: if a client sends a long stream of requests without reading
>any of the replies, slapd will eventually stop reading requests from the
>client. (Otherwise slapd will lockup as its sendbuffer gets full.) As a
>consequence of this new behavior, if the client *never* reads its replies,
>and just closes the connection, slapd will never see the close because it's
>no longer select'ing for read on that socket. (If the client *does* read a
>reply, and the socket becomes writable again, then select/read will be
>To avoid having these hung connections lying around forever, it seems we need
>the default for global_idletimeout to be non-zero, or we need a new
>idletimeout variable for "exceptional conditions" such as this.
>Also, in daemon.c, if slapd runs out of file descriptors, the
>connections_timeout_idle() function is invoked to reap some idle connections.
>However, it uses global_idletimeout which defaults to zero. This means, when
>slapd runs out of file descriptors, all connections which were not active
>within 1 second from "now" will be closed. So again, it seems we need the
>default for global_idletimeout to be non-zero, or we need a separate
>exception timeout for these emergency situations.
>I would prefer not to change the global_idletimeout default. Thoughts?
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support