[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: paged results gives invalid cookie (ITS#3089)
I discovered that through trial and error a while ago... But I solved it by simply maintaining an additional connection when I needed to do that.
The current way I'm raising the bug is through java with a single connection, doing a single search, and just trying to get all of the results. No other searches occur in between the times when I ask for more results (and since it's a testing server, I am the only client)
I just tried again using only the openldap tools, and I can still recreate it that way as well.
armbrust@mir04==> ~/openldap/ldap/clients/tools>ldapsearch -b 'dc=concepts,codingScheme=RXNorm,dc=codingSchemes,service=RXNorm,dc=LexGrid,dc=org' -E '!pr=1' -s sub -h localhost -p 32900
# extended LDIF
#
# LDAPv3
# base <dc=concepts,codingScheme=RXNorm,dc=codingSchemes,service=RXNorm,dc=LexGrid,dc=org> with scope sub
# filter: (objectclass=*)
# requesting: ALL
# with pagedResults critical control: size=1
#
# concepts, RXNorm, codingSchemes, RXNorm, LexGrid.org
dn: dc=concepts,codingScheme=RXNorm,dc=codingSchemes,service=RXNorm,dc=LexGrid
,dc=org
objectClass: concepts
dc: concepts
earch result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAsCAwqUMwQEBQAAAA==
Estimate entries: 693299
Press [size] Enter for the next {1|size} entries.
# extended LDIF
#
# LDAPv3
# base <dc=concepts,codingScheme=RXNorm,dc=codingSchemes,service=RXNorm,dc=LexGrid,dc=org> with scope sub
# filter: (objectclass=*)
# requesting: ALL
# with pagedResults critical control: size=1
#
# C0000220, concepts, RXNorm, codingSchemes, RXNorm, LexGrid.org
dn: conceptCode=C0000220,dc=concepts,codingScheme=RXNorm,dc=codingSchemes,serv
ice=RXNorm,dc=LexGrid,dc=org
version: 1
objectClass: codedEntry
conceptCode: C0000220
entityDescription: 2,4-Dichlorophenoxyacetic Acid
# search result
search: 3
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAsCAwqUMwQEBgAAAA==
Estimate entries: 693299
Press [size] Enter for the next {1|size} entries.
.
.
[snip]
.
.
0002328, concepts, RXNorm, codingSchemes, RXNorm, LexGrid.org
dn: conceptCode=C0002328,dc=concepts,codingScheme=RXNorm,dc=codingSchemes,serv
ice=RXNorm,dc=LexGrid,dc=org
objectClass: codedEntry
conceptCode: C0002328
entityDescription: Algestone
# search result
search: 60
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAsCAwqUMwQEPwAAAA==
Estimate entries: 693299
Press [size] Enter for the next {1|size} entries.
# extended LDIF
#
# LDAPv3
# base <dc=concepts,codingScheme=RXNorm,dc=codingSchemes,service=RXNorm,dc=LexGrid,dc=org> with scope sub
# filter: (objectclass=*)
# requesting: ALL
# with pagedResults critical control: size=1
#
# search result
search: 61
result: 53 Server is unwilling to perform
text: paged results cookie is invalid or old
Server is unwilling to perform (53)
# numResponses: 119
armbrust@mir04== ~/openldap/ldap/clients/tools>
Furthermore, the point where it fails changes - If I do this test repeatedly, it seldom fails on the same entry. So I don't think it's a corrupt entry in the database.
I'm not much of a c programmer, but if there is any other debug output I can generate that may shed some light, let me know.
If it would be helpful, I can publish this database for debugging. But its kind of big (about 1GB) when loaded. The ldif is 255 MB. It also has a custom schema.
Dan