Re: slapd can't handle too many concurrent BINDs

Fri, 17 May 96 16:35:58 -0700

> Again, the solution is to not run out of file descriptors. :)

Of course; but I'd lobby that the server's ~trying~ to not run out of
descriptors is 1/3 the solution (tho an equally-important third). The other
two thirds are...

2. installing slpad such that it has tons of fd's on tap (i.e. using
limit(2) to set the process's fd limit high).

3. fixing slapd such that it behaves in some reasonable manner if it does
happen to run out of fd's.

I just looked at rfc 1777, and it doesn't seem to mention timeouts on BINDs
themselves (i.e. when a BIND is done but no other client-initiated operations
are forthcoming).

However, looking through my slapd logs, it seems that slapd ~was~ trying to
discard the unused BINDs after some amount of client inactivity. In this
particular case, the wayward client was fast & persistent enough to overwhelm
it, in which case it (slapd) should have behaved per option 3 above rather
than simply hanging (and we (blush) should have installed it with a zillion
fd's rather than only 64).

Make sense?