Michael Ströder wrote:
Hallvard B Furuseth wrote:
Michael Ströder writes:
Is that really a problem? How often is "occasionally"?
Don't know, and don't know.
To me 2.5 MB does not sound so much to justify thinking about changing the client app in such a network- and data-specific way.
OK, good. I've no experience with that kind of search result sizes myself.
I can only speak of situations where I retrieve the whole directory (up to 300000 entries) for syncing. But this does not happen very often and my sync scripts call ldap_result() quite soon and process results as they come in.
getgrent() with nss_ldap. Others may come later.
Hmm, maybe that's what Volker Lendecke was talking about at LDAPcon 2007 regarding enumeration of groups. See his slides:
http://www.guug.de/veranstaltungen/ldapcon2007/slides/ldapcon_lendecke.pdf
Does it block other operations from different apps?
Don't know yet, that's what I was wondering about. Like I said I imagine it can, if the threads get blocked. We've just multiplied the server-side sizelimit with 200 to accomodate the change:-(
I guess user-specific limits won't help much.
Right. It would be possible to have slapd internally break up the results to prevent the thread from getting blocked. There's some question about whether it's worthwhile to do so (e.g. for a slow client, the time slapd spends blocked should outweigh the time it takes slapd to requeue the result processing.)