[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