[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SUMMARY: Re: cachesize does not exceed 1000 entries
Pierangelo Masarati wrote:
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.
I checked the code, and back-ldap works fine in propagating pagedResults
but, obviously, pcache doesn't (and I don't see how it could). A
possible solution is to trap the control, don't send it to the remote
server, so that the whole request is cached, and honor it only on the
client's side. This requires some programming effort on the pcache
side, which I cannot spend right now, so I chose to disable that control
form inside pcache. When it's non-critical it's simply ignored; when
it's critical, unavailableCriticalExtension is returned. This should
fix your issue as well, assuming your client is setting the control as
non-critical. Otherwise you'll have to file your feature request, and
wait for someone to implement it :).
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497