Solved: Apigee caching Key Value Map entries for longer th... - Page 2

johnferguson · 01-13-2017 02:55 PM

I have a value in a KVM which I am using to store the rate limit for a Spike Arrest.

In my proxy, I have a KVM Operations Policy to retrieve it:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<KeyValueMapOperations async="false" continueOnError="false" enabled="true" name="KV-GetSpikeArrestLimitValue" mapIdentifier="SpikeArrest">
    <DisplayName>GetSpikeArrestLimitValue</DisplayName>
    <Properties/>
    <ExclusiveCache>false</ExclusiveCache>
    <ExpiryTimeInSecs>10</ExpiryTimeInSecs>
    <Get assignTo="spikeArrestValue">
        <Key>
            <Parameter>SpikeArrestValue</Parameter>
        </Key>
    </Get>
    <Scope>environment</Scope>
</KeyValueMapOperations>

When I am changing the KVM value, the execution of this policy doesn't seem to pick up the change. My understanding of the ExpiryTimeInSecs parameter is that it should refresh after 10 seconds, but this isn't the case. Even deleting the KVM doesn't help; the old value is still referenced.

The KVM concept loses it's value in this Use Case if we can't replicate updates relatively quickly. The danger is that we knock the value down low during a difficult period, then knock it back up again, but we have no control over when the value is replicated into cache.

Am I missing something?

DChiesa

John - to answer your question, yes, you are missing something!

The behavior you are seeing is confusing but there is a simple explanation.

You had a prior version KVM-Get policy that specified an ExpiryTimeInSecs of something more than "Several hours". Maybe you used 86400, maybe something larger. When you ran the KVM-Get the first time, it populated the cache with the TTL of 86400 (or whatever you used).

The TTL of 86400 is often the used because at one point, that value was used in the same policy configuration in our documentation!

Then, you modified the KVM-Get policy to specify 10 seconds for ExpiryTimeInSecs. You re-ran the KVM-Get expecting to see the data being cached for only 10 seconds. But that expectation is wrong.

The cache would be kept for only 10 seconds IF the cache were not already populated. But the element you are trying to read is already in cache, and that cached element has an expiry (aka TTL), which you cannot change, or even see. So a KVM-Get continues to return what you consider to be "stale" data.

To escape this situation, you have some options.

Change the key. Use anything different from SpikeArrestValue. Use "Tomato". Be sure to insert an item into your KVM with that new key. This key will not have been cached. The first time it is cached it will use the value you specified in the ExpiryTimeInSecs element at the time the policy executed. (In your case, 10 seconds)
Run a KVM-Put on the same key ("SpikeArrestValue"), specifying a value of "30ps" and an ExpiryTimeInSecs element of 1. This will write the value to the KVM, and also write the value to the cache, overwriting the existing cached item and its mystery TTL. You need to do this only once. You can attach this policy to a flow that is used only temporarily, or to your existing flow. After you invoke this policy once, you can remove it. Updating the KVM this way, via policy, updates the runtime cache in the message processor. Updating the KVM via the Administrative UI or API will not flush the runtime cache in the message processor. After you run the KVM-Put just once, you can remove the policy from your proxy. Or, leave it in the proxy, protected by appropriate authorization check, to allow for future reset of the cache.

Either way will lead you to joy.

View solution in original post

Apigee caching Key Value Map entries for longer than expected