Re: (ITS#6646) back-hdb dncache disregarded in some searches

[ondrej.kuznik@acision.com]

On 09/10/2010 11:19 AM, hyc@symas.com wrote:
> This fact is already documented in the manpage. This ITS will be closed.

I disagree. The manpage states:
"It should be noted that the DN cache is allowed to temporarily grow beyond
the configured size. It does this if many entries are locked when it tries
to do a purge, because that means they're legitimately in use. Also, the DN
cache never purges entries that have cached children, so depending on the
shape of the DIT, it could have lots of cached DNs over the defined limit."

However, in the last case with the sizelimit, the DN cache grows over its
configured size permanently. They do not seem to be legitimately in use and
if they are, it is because the code that used them told noone it stopped
doing so as the sizelimit has been reached or connection severed. All those
entries are leafs, so no children either. From all this I deduced that
either the code or documentation are missing something.

And I will repeat myself, but two searches that differ only in their search
bases behave _very_ differently. If one search iterates though the database
and uses and frees the entries it processes emitting and the other one gets
all entries first and parses and releases them afterwards, and if something
interrupts it, does not release some.

But yet again, I am only slowly gaining familiarity with OpenLDAP's immerse
codebase and thus have no authority to speak about code I am nowhere near
familiar with. Still, I am eager to learn as much as I can, so I'll be glad
for some pointers.

Thanks,
Ondra

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.