Lookup Cache is not working for subsequent requests.

[amackenz-apigee]

I am having the exact same problem as described here:

https://community.apigee.com/questions/1421/lookup-cache-is-not-working-for-subsequent-request.html

My problem was not resolved by simply re-deploying and has persisted for a number of days now.

I have tried my policies in a personal Apigee account (used for training) and they worked there. But they are not working with my company's setup.

Lookup Policy:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<LookupCache async="false" continueOnError="false" enabled="true" name="Lookup-Cache">
    <DisplayName>Lookup-Cache</DisplayName>
    <Properties/>
    <CacheKey>
        <KeyPrefix>MyCache</KeyPrefix>
        <KeyFragment>cachedAuth</KeyFragment>
    </CacheKey>
    <Scope>Proxy</Scope>
    <AssignTo>creds</AssignTo> 
</LookupCache>

Populate Policy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PopulateCache async="false" continueOnError="false" enabled="true" name="Populate-Auth-Token">
    <DisplayName>Populate Auth Token</DisplayName>
    <Properties/>
    <CacheKey>
        <KeyPrefix>MyCache</KeyPrefix>
        <KeyFragment>cachedAuth</KeyFragment>
    </CacheKey>
    <Scope>Proxy</Scope>
    <ExpirySettings>
        <TimeoutInSec>20</TimeoutInSec>
    </ExpirySettings>
    <Source>creds</Source>
</PopulateCache>

Things I have tried:

1. Changing scope (Global, Exclusive, etc.)
2. Using a Prefix rather than scope
3. Using no Prefix
4. Long timeouts
5. Short timeouts
6. Duplicating my proxy from scratch
7. Using an Environment cache rather than the global cache

Nothing works. I always get a cache miss. If I include a lookup in the same flow AFTER the populate then it finds my value.

[dchiesa1]

That stinks!

And it sounds frustrating.

I apologize, but I don't think we can help you here. You will need to talk to an Apigee support person who can look directly at the logs for your particular organization (tenant) in the Apigee cloud. They may ask you for a trace session that collects data for the failure.

I would want to look at debug-level logging for the cache infrastructure, in order to diagnose this. I don't have the access to do that with your organization, to help you in that way. The Apigee support people will have the ability to do that, if you ask them for help on this.

One possibility I can imagine is... if your cache is really busy, or if your message processor is otherwise memory stressed, then the cache may eject entries "very quickly" such that a Lookup in an API call may not find a value that was inserted by an API call only a half-second ago. But., this seems unlikely in your case. I would much more expect this to occur in a shared tenant situation (your eval account) than in a commercially-provisioned organization. Your report says you see the opposite behavior of what I might expect.

Unless the MP is truly memory stressed. do you have 1000's of proxies deployed? Do you have many environments on the same MP? Lots of traffic?

Anyway getting debug logs on the cache infrastructure will help isolate what's going on. The support team should be able to sort it out.

[amackenz-apigee]

Thanks - we have a handful of proxies and the one I'm working on is the first to use caching - so it's very unlikely that we'd be stressing anything. I'll talk to support.

[dchiesa1]

Sometimes the stress in the system comes from memory pressure, and not just pressure on the cache itself. In other words the cache has to compete for memory with all the other systems. So even if you don't use cache there still may be an issue with memory contention.

But this is all just supposition and imagining. Support should be able to track it down.

[amackenz-apigee]

It seems that we can get our code to work if the <AssignTo> is to a "request.header.variable" rather than to a generic flow variable.

It also seems that the output in the trace is very unreliable and sometimes misleading for the LookupCache policy. The variable will often be shown in the policy AFTER the LookupCache and the LookupCache policy will show "cache_hit: false" (even though it appears to have found a value).