Lookup Cache not working when I cache the data using Response cache

[mark_hammelman]

I have a similar problem as this issue from 2019 (https://www.googlecloudcommunity.com/gc/Apigee/Lookup-Cache-not-working-when-I-cache-the-data-using-...) but the responses on that thread are not showing a solution.

We have proxy A using ResponseCache policies and can successfully populate/lookup cached values.

Next, we have proxy B using LookupCache to retrieve the cached responses from the same cache used by proxy A.  It is getting a 'cache hit=true' but the values dont make sense.

For troubleshooting, I added a javascript to get the flow variable set from the cacheLookup and print it to console, and the value we see are like :

com.apigee.messaging.adaptors.http.message.HttpResponseMessage@303d6cbc

Can the lookupCache policy be used to get cached responses that were added using responseCache policy?

[dchiesa1]

I don't know. . . Can you explain the use case? 

LookupCache is intended to be used with PopulateCache. 

ResponseCache does both lookup and populate for its Responses. 

What are you really trying to do? 

I think if we figured out a way to configure LookupCache to retrieve stuff populated by ResponseCache, it would be depending on an undocumented interface.  Essentially we'd have to use an undocumented thing to construct the magic cache key that gets the response we want.  And because it's undocumented, it would be unsupportable and not necessarily stable over time.  So It's probably unadvisable to do so.  But maybe there is another way to accomplish what you want. Can you explain what you're really trying to do? 

[mark_hammelman · Accepted solution]

Ok.  I was under the impression that "responseCache" was effectively the same as doing PopulateCache/LookupCache policies but just a simplified way to define them.

Based on your reply,  it sounds like we could replace the "ResponseCache" policies with "PopulateCache"/"LookupCache" policies in proxy A, and that should fix the problem. 

The general idea of what we're doing is:

Proxy A gets client details from a backend server, the response is an encoded string. 

Then many other proxies (i.e. "proxy B") can use a sharedFlow to set a header with that encoded string before requests go to their targetServers.  

The idea was for the sharedFlow to check the cache first, and if found, great, it can set the header.

If not found in the cache, it does a service-callout to proxy A, and then it uses the SC response to set the header. Since proxy A also populates the cache, it will already be there for any subsequent requests.

[dchiesa1]

Yes, what you describe is what I would do!