Cool. I've looked at pcache.c, and realized I'm a noob with this code.

Basically, my thoughts, is that pcache should ignore the incoming search request, and recreate it's own with it's own options, always asking for paging. Then page through all the results from the backend, then store the full set in the backing store.

While that is going on, the cache entry should be marked with a bit flag saying that it's in the process of being built, but otherwise can still store the entries fetched thus far.

Meanwhile, the frontend request can begin to return results from this partially resolved backend entry stored in the cache, utilizing whatever pagination value(and or offset/limit) has been requested.

Of course, that's just the high-level description, not even really pseudo-code ready.

As an aside, and this s/b a separate bug, if an error occurs from the backend this does *not* get cached. Aka, during this investigation, my backend is returning 2000 entries, err=4. This takes 7s each time(I'm in Dallas, while the backend is in California, and I'm communicating over a tunnel). It's not cached, so the request is passed through each time. I've configured the templates correctly, and the debug shows that the request is CACHEABLE.

On Wed, Sep 6, 2017 at 6:22 PM, Quanah Gibson-Mount quanah@symas.com wrote:

--On Wednesday, September 06, 2017 7:06 PM -0500 Adam Heath adam@brainfood.com wrote:

...

Well, then since you are confirming the bug, I would say this ticket should *not* be closed.

I already reopened it. ;)

...

I might just have to patch this to make it work.

Make sure you follow the contribution guidelines:

https://www.openldap.org/devel/contributing.html

Thanks,

Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com