RE: paged results gives invalid cookie (ITS#3089)

[Kurt@OpenLDAP.org]

I suggest you enable full server-side logging.  Of particular
interest would be the hexdump of the server's response
immediately prior to the client's last request, and the
client's last request.
        Kurt

At 11:17 AM 6/18/2004, Armbrust.Daniel@mayo.edu wrote:
> 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