On 4 Nov 2008, at 09:26, Pierangelo Masarati wrote:

toby@inf.ed.ac.uk wrote:

...

Hi there, is there any further debugging I could usefully carry out for this issue, or does it need someone who understands the code a bit better?

It's not a debugging problem, but rather a design issue. The current design makes use of the first AVA of the filter to decide how two filters are compared. In your case, the first component is common to all filters, so only the first occurrence of a search with that template can be cached. This fact, to my knowledge, is undocumented, but there's little to do except redesign this weighing criterium. As I already pointed out, you need to make the most significant filter AVA appear first in your filter template. Unless anyone voluteers for a complete redesign [*] of this portion of slapo-pcache(5), I take your ITS as a request to document this aspect of template design.

p.

[*] a complete redesign could also get rid of strict ordering of filter AVAs, allow "static" portions of the filter (something like (&(objectClass=person)(uid=)) and so) and other relatively unfriendly aspects of slapo-pcache(5) configuration.

The problem with changing the ordering in the template is that it then doesn't match the real lookups that occur and so the entries aren't cached - this is something over which I have no control - e.g. queries generated by 'ls -l', or by somebody logging into the machine, etc, etc. This is why we have the filters this way.

e.g. sshing into one of our scientific linux 5.2 hosts generates the following lookups:

[sybies]toby: grep 'query template' ~/tmp/pcache-login |cut -d' ' -f13| sort|uniq -c 1 (&(objectClass=)(cn=)) 2 (&(objectClass=)(|(memberUid=)(uniqueMember=))) 28 (&(objectClass=)(uid=)) 5 (&(objectClass=)(uidNumber=)) 26 (&(objectClass=)(uniqueMember=)) [sybies]toby:

Cheers Toby