No way to expire KeyValueMapOperations internal cache

sgarg24
Participant II

We are having a challenge with using KeyValueMapOperations policy. When we implemented the code few years ago, we have defined the KVM policy to have expiry value as 30 days.

<KeyValueMapOperations .....>

<ExpiryTimeInSecs>2628000</ExpiryTimeInSecs>

This documentation clearly says that cache can be cleared when an entry is updated using PUT request. But the latest API docs does not list the PUT operation as a valid operation anymore.

Moreover, when we attempted the PUT request in postman, the call is successful but the internal KVM cache is not cleared:

https://api.enterprise.apigee.com/v1/organizations/{org}/environments/{env}/keyvaluemaps/{kvm_name}/...

We even deleted the entry altogether, still the KVM continues to fetch the value from some internal cache. Is there a way to invalidate this on Apigee Edge cloud?

Solved Solved
0 3 155
1 ACCEPTED SOLUTION

Not applicable

I would suggest to create a proxy with KVM policy using which you will do the PUT operation. That will help you clear cache.

management api call doesn't work in this case.

View solution in original post

3 REPLIES 3

Not applicable

I would suggest to create a proxy with KVM policy using which you will do the PUT operation. That will help you clear cache.

management api call doesn't work in this case.

Thanks, creating a test proxy and executing the PUT operation via the API proxy did invalidate the cache.

Although the only confusion is why the GET management api reflected the change in Postman but not the Read operation. Ideally both should have same behavior. This looks like a bug in the Edge APIs.

the GET management api reflected the change in Postman but not the Read operation. Ideally both should have same behavior. This looks like a bug in the Edge APIs.

I guess the phrase "Read operation" in your statement refers to the KVM Get policy.

In that case, the behavior you observed is working-as-intended.

The cache for KVM is held in the message processor, and is independent of the management API or even the persistence layer.