Re: Altering the behavior of pcache to improve cache hit/miss ratio

[Ryan Steele <ryan.g.steele@gmail.com>]

Before I respond, I should preface this message by noting that this is probably no longer a development question (or at
least, it is starting to become tangential), so I'm happy to repost this to openldap-software if desired.  I just didn't
want to do that without verifying that it would not be considered as cross-posting.

Howard Chu wrote:
> Ryan Steele wrote:
>> Hey folks,
> 
> You have no idea what you're talking about, and pcache doesn't work as
> you describe. Nor does "id" or nss for that matter.

I've got no problem being be told I'm wrong, and welcome the chance to learn in the process.  If you're right (and I've
got no doubt you are given your knowledge of the subject is far deeper than my own), and the second half of my response
clears up the confusion with respect to the semantics of attributes versus filters in this context, how can you explain
the behavior in the following slapd output?  When slapd receives a query in which an attribute list is specified,
everything works; when it doesn't, the call to "id" hangs.  The only difference I can discern from the output is that
the second query is missing an attribute list.  This is, in fact, what happens when I run "id ryans".  When I firewall
off the LDAP server, the id call hangs when it gets to the query in which there is no "SRCH attr", which causes the
request to be proxied out to my remote LDAP server (an occurrence for which the evidence is documented below).  I have
more complete logs if you cannot make a determination from what I provide here:

## query with SRCH attr specified
conn=1 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=ryans))"
conn=1 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
query template of incoming query = (&(objectClass=)(uid=))
Entering QC, querystr = (&(objectClass=posixAccount)(uid=ryans))
Lock QC index = 0x7f6b83aa8d10
Not answerable: Unlock QC index=0x7f6b83aa8d10
QUERY NOT ANSWERABLE
QUERY CACHEABLE


## same query with no SRCH attr specified
conn=1 op=3 SRCH base="dc=aweber,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=ryans))"
query template of incoming query = (&(objectClass=)(uid=))
QUERY NOT ANSWERABLE
QUERY NOT CACHEABLE
ldap_create
ldap_url_parse_ext(ldap://remotehost.example.com)
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP remotehost.example.com:389


> 
> It is illegal for an LDAP search to have an empty filter. Go back and
> read RFC 4511 before posting nonsense like this.


I have read the RFC.  I simply used the incorrect terminology - what I meant is, it has an empty attribute list, as
denoted by the post above.  I'll be more careful when articulating issues in the future to avoid this sort of
miscommunication and/or confusion.  And again, if you would like me to change the venue to openldap-software, I'm more
than happy to repost it there, I just didn't want to cross-post before confirming.


Cheers,
Ryan