[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6152) proxycache enhancements



> masarati@aero.polimi.it wrote:
>> I wonder, in the spirit of further improving pcache:
>
> I think this should be a separate ITS.

Well, based on your response, it seems not to deserve an ITS at all :)

>> - support compare, in case a cached query has the entry to be compared,
>> and the asserted attr is in the corresponding attrset?
>
> Right now we have no convenient way to map a DN to a cached query.

We have: a cached entry contains the pcacheQueryID, which solves the problem.

> I guess
> we
> could answer if the entry was already retrieved by some other query, but
> we
> can't tell what the queryID is without first retrieving the entry.

Correct.

> If the
> entry doesn't exist locally, we have no way to map the request to a query
> template, so we can't cache that result at all.

I was not concerned with *caching* the result of compare, but with
exploiting cached entries to answer compares without contacting the remote
server.

> It seems to me that apps
> that
> do Compares on a set of entries do that to avoid Searching and retrieving
> the
> entire entry, so in practice the intersection of (entries cached by
> searching)
> and (entries we want to compare on) will be empty.

:)

>> - exploit modifications to invalidate queries whose results are altered?
>> It'd be easy for deletes (check if present, and eventually remove the
>> entry).  An easy shortcut for modify/rename would be to just invalidate
>> queries affecting the modified entry (I'd prefer this to mimic
>> modifications to local data, which would also guarantee that remote
>> server
>> ACLs have been applied).  Adds would be a little bit tricky (try all
>> cached queries on the new entry (base, scope, filter; in case of match,
>> invalidate them, so that the remote server can apply ACLs).
>
>> This may be a moot point, as usually cached proxies are essentially
>> read-only, but in case...
>
> So far no one has asked for this functionality, thankfully.
>
> We can retrieve an entry and read its queryID but we don't currently have
> an
> easy way to look up the ID to get the CachedQuery info.

This is all already in place as the PCACHE_EXOP_QUERY_DELETE.

> (I guess we can
> put
> them all into an AVL tree for the purpose.) That would make Deletes easy
> enough I guess. For Modify/Rename, if you invalidate a query do you then
> delete all of the cached entries for that query? That could result in a
> lot of
> write traffic for a single change.

pcache is probably based on the assumption that clients only perform
search (and now, bind) operations, so it's a moot point anyway.

> Or do you just leave the cached entries
> alone, and destroy the CachedQuery structures? Then the entries will
> simply
> have queryIDs that reference nonexistent queries.
>
> Yeah, Adds could result in a lot of invalidations too, with the same
> question
> about dangling queryIDs.

Codewise, it's a matter of just calling
pcache_remove_entry_queries_from_cache() for the request DN, if the
modification succeeds.  Performance and load-wise, it might not be worth,
I concur.

p.