KVM updates taking too long to reflect

[naniwadb]

Hi,

Recently we are noticing exceptionally long waits in the range of 30-40 minutes to see the KVM value updates to go live. Creation of KVM is almost instantaneous however subsequently changing a single value from web UI takes forever to reflect in the execution flow.

Is this issue account specific or across the platform?

Thanks,

[dchiesa1 · Accepted solution]

---

@naniwadb wrote:

subsequently changing a single value from web UI takes forever to reflect in the execution flow.

---

Normally you would attach a KeyValueMapOperations policy in the API Proxy to retrieve some value from the KVM. When you do that, you can configure the policy to specify an "Expiry time" . 

<KeyValueMapOperations name='KVM-1' mapIdentifier='nameOfMap'>
  <Scope>environment</Scope>
  <ExpiryTimeInSecs>300</ExpiryTimeInSecs> <!-- LOOK HERE -->
  <Get assignTo='variable.to.set'>
    <Key>
      <Parameter ref='variable.containing.key'>fallback-value</Parameter>
    </Key>
  </Get>
</KeyValueMapOperations>

Have you specified that expiry time?  What is it?  

It is expressed in seconds.  Have you set it to be 60*30 or 60*60?  If it is 3600, then the observed behavior would be expected. 

If it is not set, then.... I don't know what it defaults to.  I suggest that you set it. 

What version of Apigee are you using?

[naniwadb]

Thanks for pointing that out. Using Apigee Edge public.

[API-Evangelist]

There is a way to force kvm cache refresh which works as explained.
https://www.googlecloudcommunity.com/gc/Apigee/How-to-refresh-the-KVM-cache-forcefully/td-p/52758
Probably this is going to be very common challenge across kvm operations & building a tool in-house helps managing kvm at will.
https://docs.apigee.com/api-platform/reference/policies/key-value-map-operations-policy
 ==
* There is no way to manually reset the KVM cache. However, you can create a temporary policy that executes a one-time PUT operation with a short <ExpiryTimeInSecs>. This will reset the cache, which contains the value you PUT, for the number of seconds you specify.

==

[dchiesa1]

yes, thank you for pointing this out. 

The reason this is important - the reason it is important to be able to "Reset the cache" - is because changing the policy configuration to use a smaller Time-to-live (TTL) does not reset the cache.  This means even if you change your KVM policy to use a smaller expiry, you may still get stale data!  The cache is already populated! 

Consider this order of events

1. configure an API proxy with a KVM policy, specifying a ExpiryTimeInSecs of 86400.  That is 24 hours.
2. invoke the proxy.  For the first request, the KVM policy checks the cache.  Finding nothing in cache, the policy reads from the persistent store, and inserts the value it read into cache. It returns that value to the API proxy. 
3. Now use the administrative API or UI to update the KVM value. 
4. at some later point, let's say 10 minutes later, Invoke the proxy again.  The KVM policy will check the cache and find a value.  It returns this value to the API proxy. It never reads the updated persistent store.  
5. Change the KVM policy to use a smaller value for ExpiryTimeInSecs.  Let's say we change it to 120.  2 minutes!
6. Invoke the proxy again.  The KVM policy will check the cache and find a value.  The value was initially inserted into the cache with a TTL of 86400, so it remains in cache.   The policy returns this cached value to the API proxy. The policy never reads the updated persistent store. 
7. Keep invoking the proxy, and for the next 24 hours, the proxy will see stale data.  The ExpiryTimeInSecs is never used, because that applies only when inserting things into the cache, which means it applies only when reading from the persistent store. That configuration value does not apply when the KVM entry is already in the cache. 

This is why you may wish to reset your cache. Rather than wait 24 hours, you can just PUT a value (even the same value) via the KVM policy.  And use a smaller ExpiryTimeInSecs with the PUT.