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

Re: SUMMARY: Re: cachesize does not exceed 1000 entries

Quanah Gibson-Mount wrote:



--On Saturday, September 03, 2005 7:12 AM +0530 Sameer N Ingole <strike@proscrutiny.com> wrote:

Robert Petkus wrote:

Folks,
I finally found the problem after much frustration --> Solaris. Once
I tried the same query on Linux and was able to retrieve >1000 entries
I figured the problem was with the ldap client on Solaris.
Looking in the logs, Solaris was using paged results from back-bdb.
When doing an ldap query that consults nss_ldap such as "finger",
libsldap.so is hard-coded with a LISTPAGESIZE of 1000 (see
http://cvs.opensolaris.org/source/xref/usr/src/lib/libsldap/common/ns_in

ternal.h). I grabbed source for libldap from openSolaris.org,
increased the pagesize limit, and hacked it so it would work on Solaris
9 and lo and behold it worked -- I was able to to retrieve >1000
entries.

However, I didn't feel comfortable putting my hacked libraries on
production Solaris servers so I stripped all the pagedresults controls
from back-bdb/search.c and this worked, too, with default Solaris.
This is how I'm going to leave the system for now.
Is it possible to request greater freedom over these controls (e.g.,
pagedresults) in a future version of openldap?



Yes, file an ITS. Request feature. Refer to Openldap web site.
http://www.openldap.org/its/

Regards,


I fail to see how filing an ITS is going to fix a hard coded limit in the Solaris code. If the Solaris code is quite clearly requesting a control, and limiting it to 1k entries, then OpenLDAP is simply doing what as requested of it. There is no bug in the OpenLDAP code here, so really no issue to file an ITS about. Solaris is what is broken. What essentially is being asked here is to tell OpenLDAP to *ignore* a requested control, which would be very broken behavior.

The point seems to be little related to OpenLDAP software, if the issue reduces to Solaris client __always__ requesting that control with that pagesize. The question is: what does the client __really__ need? Does it
a) only need the first 1000 entries (i.e. abandons the request after the first 1000 are returned, or
b) request for subsequent pages?
If the answer is (a), then OpenLDAP software is just behaving as expected. If the answer is (b), then there __might__ be something not working as expected in the back-ldap/slapo-pcache chain that doesn't handle the pagedResults control as expected/reasonable. I say __might__ because I haven't considered yet what would be the reasonable behavior of that setup when the pagedResults control is requested. In principle, back.ldap should propagate pagedResults correctly (actually, by design it is supposed to propagate all controls the frontend can successfully parse). I think the latter case is worth investigation, if your traffic shows that the client is actually requesting subsequent pages but OpenLDAP software doesn't actually honor the request.

p.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497