Issue in keeping a common LookupCache policy with different cache keys

Google Cloud Apigee
1

Pleas see below

<Step>
	<Name>Cache.lookupCoreServiceCalloutGET</Name>
</Step> 
<Step>
	<Condition>lookupcache.Cache.lookupCoreServiceCalloutGET.cachehit != "true"</Condition>
    <Name>Assign.setCalloutVerbGET</Name>
</Step>
<Step>
	<Condition>lookupcache.Cache.lookupCoreServiceCalloutGET.cachehit != "true"</Condition>
    <Name>Callout.genericServiceCallout</Name>
</Step>
<Step>
	<Condition>lookupcache.Cache.lookupCoreServiceCalloutGET.cachehit != "true" and serviceCallout.Response.status.code=200</Condition>
	<Name>Cache.populateCoreServiceCalloutGET</Name>
</Step>
This time cacheKey will be different but policy name is same. key is changed prior tothat.
<Step>
	<Name>Cache.lookupCoreServiceCalloutGET</Name>
</Step> 
<Step>
	<Condition>lookupcache.Cache.lookupCoreServiceCalloutGET.cachehit != "true"</Condition>
    <Name>Assign.setCalloutVerbGET</Name>
</Step>
<Step>
	<Condition>lookupcache.Cache.lookupCoreServiceCalloutGET.cachehit != "true"</Condition>
    <Name>Callout.genericServiceCallout</Name>
</Step>
<Step>
	<Condition>lookupcache.Cache.lookupCoreServiceCalloutGET.cachehit != "true" and serviceCallout.Response.status.code=200</Condition>
	<Name>Cache.populateCoreServiceCalloutGET</Name>
</Step>

Now the question is there any way in which we can check lookupcache.Cache.lookupCoreServiceCalloutGET.cacheKey.cachehit which allows us to use same lookup cachepolicy and cacheHit is identified from key also instead of policyName.

2

Hi,

We have a similar issue where we have a Cache Lookup policy in a shared flow, which is called twice from a proxy, each call causing a unique cache key. When the cache entry supposed to be returned by the second call expires while the first one is still in the cache, the .cachehit variable is not updated to ‘false’ but remains ‘true’ after the second call. As the succeeding policies test on .cachehit being not ‘true’, they are not executed and we don’t obtain the value to be cached. Things go back to normal only after the first entry expires too.

Does anyone happen to have an explanation to this or any workaround suggestion? Thanks.

Regards,

-inan.

3

Can you provide policy config, trace session and request details?

4

Hi,

I cannot share the current solution but will try to create a simpler case to demonstrate. Thanks.

1 Like