[Date Prev][Date Next]
RE: How to set new paged result limit [WAS] RE: Paged results flakey - and hdb vs bdb
> Allright, I did a cvs update this morning, and ran some additional tests
> today. (There's even s slight chance you might see this e-mail before
> noon, but I seem to have about a 4-5 hour delay between when I sent
> mail, and when it shows up on the list... And then it doesn't even
> arrive in the order I sent it... Very odd.) Here are the results:
> size.pr=int - works
> size.pr= none - works
> size.pr=noEstimate - works
> size.pr=disabled - doesn't work - when I set this to disabled, I expect
[masarati@mbdyn ldap]$ ldapsearch -x -H ldap://:9009 -b 'cn=monitor' -E
# extended LDIF
# base <cn=monitor> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with pagedResults critical control: size=9
# search result
result: 12 Critical extension is unavailable
text: control unavailable in context
Critical extension is unavailable (12)
# numResponses: 1
This is from HEAD; maybe you tried REL_ENG_2_2
which is not aligned with HEAD yet. This code
has been reviewed many times in the past 24 hrs
because there were severe bugs in it. Hope you
can test the current HEAD code quite soon to have
extra feedback before it's released.
> it to give me some sort of an error when I make a search with the paged
> results controls set - it doesn't give any error, and furthermore, it
> allows me to page through the results. It seems to have the same exact
> behavior of "none". I'm doing my testing from java code, by the way.
> If that makes any difference.
> size.prtotal=int - works
> size.prtotal=none - works
This syntax will likely change soon; right now it
should work as intended. The same functionality
(specific pagedResults max limits different from
regular ones) will be provided with different
syntax. Since its introduction is quite recent,
I guess no backwards compatibility will be provided.
> I see the man pages have been corrected now. The only other thing I
> would mention it that is while it probably should have been obvious to
> me that I could just use a * for the <who> part of the limits command,
> until I saw your example I was writing two lines, one for users and one
> for anonymous.
> I was just about to send this message, but I had let one of my tests run
> longer in the background while I wrote this - and now it looks like the
> dreaded "LDAP: error code 53 - paged results cookie is invalid or old"
> error is back.
I'll look a bit more to this. Sorry.
> I was paging through a query results (which had an estimate of 24547
> results) 5 at a time. When I got to a result somewhere around 4000, it
> kicked out the invalid cookie error. So then, I ran my code again, and
> now it kicks out the error the very first time I ask for a paged result
> (so result 6-10).
> I restarted the server (another bug - with yesterdays code the server
> halted properly when I did a Ctrl C - today it doesn't, I have to kill
> -9 it again) and tried again. This time I got through 4085 of them, and
> it kicked out the same error again. And again, it wouldn't allow me to
> do any more paged results until I restarted the server.
This looks definitely like there's some error in bdb
that is triggered by pagedResults control. I'll let
you know. You should definitely file a separate ITS
for the invalid cookie error; I think the rest is