lookupcache.LookupCachePolicy.cachehit shows either true or false across request.

Google Cloud Apigee
1

So I have an API endpoint that creates a Cache and validate if that cache exist. However the Lookup Cache policy shows different responses across repeated request of the same payload. It would show either true or false across multiple request. Why is this so?.

9559-screenshot-812.png
9559-screenshot-812.png436×735 38.7 KB

The Flow variables lookupcache.LookupCachePolicy.cachekey & lookupcache.LookupCachePolicy.cachename are the same across all this request anyway but still the cachehit value would either be true or false even though the value exist in the cache.

2

What’s the time frame between populating the cache and the cache lookup requests?

3

1-3 seconds. But even with greater delay in the succeeding requests. The cachehit value would still either be true or false. It is soo random.

4

Apigee has two-level Cache implementation.

If value is located in MP’s in-memory cache, L1, it is returned. If a value is found in a Cassandra cache, L2, it is returned an MP’s in-memory cache is populated.

If a value is not found, then your policies will fetch the value, will put it into Cassandra cache and into in-memory cache if an MP processing your request. Meanwhile Cassandra will propagate this value across all nodes. Next time when another MP processes your request, the value is fetched from Cassandra then server from in-memory cache of that MP.

This means there are actually two .cachehit values: one corresponding to the L2 cache and one, corresponding to the L1 cache.

Confusingly, TRACE output shows L1 .cachehit results, even that the Lookup policy uses .cachehit result for L1/L2.

If I take a sequence of a cache-enabled proxy, I typically should observe following picture:

Request 1, displays false for the .cachehit, some policies fetch the value. It takes 126 milliseconds in this case.

Because my Trial Org has 4 MPs, There are three other false values, corresponding to the scenario when a value is not found in L1 and fetched from L2. A request to Cassandra at that infrastructure takes 3 to 5 seconds (requests 2, 3, and 6). .cachehit value is false for L1, reflected, but true for L2, not shown.

Then subsequent calls fetch the value from L1, (all 3 sec requests) and the cachehit values is false.

Summary.

Even though Apigee processes Lookup cache correctly, it displays results misleadingly to be useful.

Apigee TRACE facility needs either introduce .cachehi1L1 and .cachehitL2 values or display aggregated L1/L2 value to be meaningful.

3 Likes
5

Yuri, so helpful! Thanks.

6

Hi @Dino-at-Google , this seems to be an issue in Apigee really. Moving the Lookup Cache Policy to response flow doesn’t give me consistent responses again. Could be an update or whatsoever in Apigee as I could not get consistent response of cachehit again. See responses below of my Validate Session API that is the same session across request. What should I do or wait for an update regarding this?. We’re using this session validation alot and we can’t just have inconsistent cache hits due to @ylesyuk has already explained.

Or what flow variable can we use to detect if there is a cache value or not?. The cachehit flow variable is not really just that so reliable at all.

9572-screenshot-835.png
9572-screenshot-835.png540×777 50 KB

7

Hi Joshua,

The situation is not as dramatic, as you are trying to point.

The only thing currently broken is displaying of logical .cachehit status in TRACE output of LookupCache policy. The variable of lookupcache..cachehit is correct if/when used in subsequent step condition or subsequent policy.

Here, I’ve attached a proxy that illustrates what is going on.

For a Lookup Cache policy called cachepol, the first column is the value of cachepol in the TRACE output, second column is the expression Result of the condition on Populate Cache policy AND result of .cachehit expression used in Assign Message of the 4th policy. You also can track visually if Populate Cache policy was executed or skipped by grey circle overlay.

The policy processing is correct. The only one who’s inconvenienced and confused is a person who interprets TRACE output.

It still needs to be fixed, of course, but it does not make the issue critical.cachepol-rev2-2020-01-10.zip

1 Like
8

I have used a step condition where lookupcache..cachehit is being used. It is where I trigger a RaiseFault whenever a cachehit is not made. But still, it is still returning either true or false across multiple request so the Response of the API would be an Error due to the RaiseFault being triggered randomly across multiple request. We could not get a reliable response from the cachehit at all. Thing is, we rely this alot on all our APIs. But the Policy itself is not working as we we’re expecting it to be, or at least give as consistent cachehits since the record of the cache exist anyway. or did I misunderstood something?. Is there really any other way we could get reliable cachehits in our Lookup Policy?

9

Okay, so after a few days of going back and forth and retesting the Lookup Cache Policy alot but still getting the same issue. I found out that even though the issue is on the Lookup Cache API, the real issue was caused by the Invalidate Cache Policy. As this never happened to us before when we implemented this with OAuth where there’s also a Lookup and Populate Cache policy but with no Invalidate Cache Policy

At first was, I tested whether if the Invalidate cache really invalidates the proper cache, and its doing so anyway, and it does not invalidate the latest cache that I know should exist. But for some reason, the cache that I know should exist, keeps on saying on every other request that the cache does not exist and then exist again, which add to me suspecting that the Lookup Cache policy not working properly as @ylesyuk is pointing out (I also encountered this sometimes before, but not on a frequent basis such as this one).

However, since I know the Issue only exist whenever I start using my Invalidate Cache Policy. I stopped testing and debugging the the Lookup Cache policy to which I am having issues retrieving the proper cachehit values and instead focused on Invalidated Policy even though it is working properly as it is invalidating the proper Caches.

Turns out, since my Caches share the same static , and I have in my Invalidate Cache, and that my only differs on the 2nd dynamic based on UUID, the Invaldiate Cache it seems to be invalidating the other cache it shouldnt be invalidating on some MPs on what it seems to me. As the cache would still return the proper values on succeeding request. So the fix was that I just removed

<PurgeChildEntries>true</PurgeChildEntries>

in my Invalidate Cache Policy.

My question now really is what is the real use of this parameter and is there further elaboration of its use as the documentation barely explains its full use. I initially thought that this property would just invalidate all caches on all MPs and all keys with the same KeyFragment. But for some reason, it seems to be randomly invalidating caches (otherwise not in the reference value of KeyFragment) on some MPs that has a different KeyFragment like the one below

<KeyFragment>Authorize</KeyFragment><KeyFragment ref="request.queryparam.SessionId">

where SessionId is always changing. Leading me to this issue where the Lookup Cache Policy would sometimes always find the Cache I’m looking for and sometime it wouldn’t and randomly throw either true or false in the cachehit response. But then one of the cause it took me longer to find the issue was that, I expected property to actually delete all records with the same KeyFragment, cuz if it did, it would always return false even though I know the cache should exist, rather, it seems to be not doing so and just invalidates cache on some MPs but still retain some randomly, hence the intermittent values I’m getting in the Lookup Policy.

Is this how it is supposed to work? @Dino-at-Google . Thx.

10

Yes even i am facing same issue with OPDK, and Agree on, The only thing currently broken is displaying of logical .cachehit status in TRACE output of LookupCache policy. The variable of lookupcache..cachehit is correct if/when used in subsequent step condition or subsequent policy.

2 Likes