Clear Internal cache custom attribute

[olofhaglund]

I there a way to clear the internal cache Apigee has? I have an issue that on the first request a developer sends, a session ID is generated and added as a header. I make an Api call to add the ID to the developers add as a custom attribute. All requests made during 180 seconds will generate new IDs since Apigee uses a cached version of the custom attribute before I entried the ID.

The reason I generate the ID during first request is that I would want in the future to generate new IDs depending on time since last request.

[dchiesa1 · Accepted solution]

Yes and No.

Yes, There is a way to clear the cache (invalidate the cache) that is populated through LookupCache or PopulateCache. There's an InvalidateCache policy for that purpose.

No, There is no way to clear the implicitly-managed cache of developer information maintained by the Apigee Edge runtime. This includes cached custom attributes on the developer, or developer app, or API Product.

In light of that, I think it would be good if you did NOT add an attribute to the developer app at runtime, from within your API Proxy.

First, that is an anti-pattern. From your description, I think what you are doing is invoking the Management API to alter the developer app, from within the API PRoxy itself. This is a Terrible, Horrible, No good, Very bad thing to do. The API runtime is designed to handle hundreds of thousands or millions of requests per second. The management API is not. I don't know what the guarantees are, but let's say it will be on the order of 1 request per second for your organization. If you have a load of 10 rps on your API, and you try invoking the mgmt API endpoint at 10 rps, you may cause backups in your online API, and also you may receive 429 responses (rejections) from the mgmt API. Don't do it. Do NOT invoke the Mgmt API from within an online API.

Second, There's a better way to do what you want. Just manage the cache explicitly.

<PopulateCache name='CP-1'>
  <CacheResource>my_cache</CacheResource>
  <Source>variable.containing.value.to.be.cached</Source>
  <Scope>Application</Scope>
  <CacheKey>
    <Prefix>session_cache</Prefix>
    <KeyFragment ref='access_token' />
  </CacheKey>
  <ExpirySettings>
    <TimeoutInSec>180</TimeoutInSec>
  </ExpirySettings>
</PopulateCache>

This allows you to explicitly manage a cache entry, per access token. You can then use LookupCache to read from this cache,

<LookupCache name='CL-1'>
  <CacheResource>my_cache</CacheResource>
  <AssignTo>variable.that.will.receive.the.value</AssignTo>
  <Scope>Application</Scope>
  <CacheKey>
    <Prefix>session_cache</Prefix>
    <KeyFragment ref='access_token' />
  </CacheKey>
</LookupCache>

and later you can use InvalidateCache if you want to reset it explicitly.

This cache, unlike the mgmt API, is designed to handle high concurrency.

[cladius_fernand]

Thanks @Dino-at-Google, for the detailed answer and elegant solution.

@Olof Haglund, could you please either accept Dino's answer or let us know if you still have some concerns?