ResponseCache gives old and new content in a pattern

[anonymous]

Hi guys.

I am trying to implement the ResponseCache Policy and I have attached it to a TargetEndpoint because I just want it to run in preprod. I have created a custom flow with a Invalidate Cache Policy so I am able to clear the cache on an item.

The cache seems to work as expected. First request goes to the backend and the next is served by the cache - all good. If I try and clear the item this works fine as well.

But if I clear the item in the cache an quickly request the API endpoint again multiple times I suddently get old and new content and it’s in a clear pattern. First I get old and then new then old then new and so on. If I trace the request I can see that alle the requests trigger the ResponseCache and it’s with the same key and environment - but the content is old and new. What is going on? I am so confused

[anonymous]

Hi @roje, can you also add your Invalidate Cache XML configuration.

Your Invalidate cache should look something like this,

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<InvalidateCache async="false" continueOnError="false" enabled="true" name="Invalidate-Cache-1">
    <DisplayName>Invalidate Cache-1</DisplayName>
    <Properties/>
    <CacheKey>
        <Prefix/>
        <KeyFragment ref=""/>
        <!-- use the same key fragments which you have used in response cache -->
    </CacheKey>
    <CacheResource/>
    <Scope>Application</Scope>
    <CacheContext>
        <APIProxyName/>
        <ProxyName>API Proxy</ProxyName>
        <TargetName>preprod</TargetName>
    </CacheContext>
</InvalidateCache>

[anonymous]

Hi @Siddharth Barahalikar

Sure. Please see the image below. As I mentioned I seem to be able to clear the cache just fine. The first request after a cache clear does give the expected data. But if I send multiple request fast after the invalidate I suddenly experience the issue described.

I just tried again. If I give Apigee a couple of seconds before calling again after the Invalidate Policy then I get the new data consistently.

[anonymous]

Here is the trace where I clear the cache first. Then second request takes 435ms (uncached) and then the next request 10ms (cached)

[anonymous]

Thanks for the screenshots, may I know why you are using different KeyFragments in Invalidate cache when compared with Response Cache KeyFragments?

Did you try using the same KeyFragments in both the policies?

[anonymous]

Hi @Siddharth Barahalikarthe - the ResponseCache uses the information gathered in the JWT when the user is fetching data from the API. The cache clear endpoint is a system endpoint and have a different authentication method and needs the same values as those collected from the JWT token.

Attached is images showing values from the JWT request and from the cache clear request. The last one again shows the trace when clearing and fetching the user again. The cache is cleared.

ResponseCache key from the normal request

Form parameters used when clearing the cache

Trace from clearing cache and populating cache again

[dchiesa1]

You are seeing inconsistent results from your cache.

Not sure about your configuration. It’s possible you have your ResponseCache policy configured incorrectly, or attached incorrectly.

I just tried this with PopulateCache and LookupCache, and it works repeatably, as expected.

Please find attached an API proxy that behaves correctly for me.

apiproxy-jwt-cache.zip

[anonymous]

Hi @Dino-at-Google

Thanks for the proxy. I tried it out and I dont see any inconsistences as you mention. I must have done something wrong.. that said your example does not use the InvalidateCache policy.

Can I ask you why you dont use the ResponseCache policy and relies on the Lookup and Populate policies? I havent fully understod the differences.

[dchiesa1]

Hi -

The reason I use Populate and Lookup Cache policies is just to simplify the model for myself.

I like the simplicity of the operation of those “cache primitives”, if you want to call them that. The ResponseCache does some other things, including sending the response directly. I’d prefer to deal with that explicitly, just my preference.

Not sure if InvalidateCache is pertinent to the behavior you’ve observed. Possibly. It warrants more investigation, and I’m interested to hear what you learn as you look into it. I had expected that just letting the cache “expire” would be equivalent to InvalidateCache, but that’s not necessarily a solid assumption to make. I suppose that’s the intent of the InvalidateCache, but maybe it is behaving incorrectly in some cases. Worth exploring.