Dynamically adjust cache duration?

[Leonardo-Ferreira]

Is it possible to dynamically change the cache duration? I would like to have a configuration in app configuration to govern how frequently the cache should be renewed, and then I could adjust it without having to restart the app.

This is important because, for example, when we launch a new feature we decrease the cache to about 30s and as we get more confident about it, we up this to 1m, then 5m, then 10m... each one of these requires a whole new deploy

[drago-draganov]

@Leonardo-Ferreira
Using AppConfiguration provider, the configuration is loaded at startup and revalidated via a sentinel key (aka ConfigureRefresh) on your desired probing interval. There isn't particular cache expiration of the already loaded configuration settings. If the provider detects a change (on the sentinel key), then refreshes the configuration. In any other case the configuration stays as is.

Do you prefer to dynamically adjust sentinel key probing interval?

[Leonardo-Ferreira]

@drago-draganov
When you plug your code to app configuration and passes on the connection string, you can set the local cache duration which defaults to 30 sec and that is the config I meant

[drago-draganov]

This is indeed the probing interval for registered settings (sentinel key) for refresh. Basically, how long to wait before checking again if modified. It controls the frequence of checks for refresh. Your configuration will not be reloaded, unless the sentinel key is updated, regardless of that frequency.
I see how the naming may be confusing though.

[Leonardo-Ferreira]

thanks, but the question remains: can I adjust that dynamically?

[drago-draganov]

There isn't anything built-in at the moment to allow that.

How would you prefer to adjust it dynamically? Ideal case.

[Leonardo-Ferreira]

I see two good options that somewhat overlap each other:

1. When configuring (at startup) you could provide the path to a configuration within that same app configuration indicating the cache duration, this way as the value changes on app configuration root, the duration of cache would reflect that change (TBD: should this value respect Sentinel rules?)
2. At portal level, you could define a global value for cache duration, which would work like suggestion 1

The order of overwriting would be:

• No settings defaults to 30 sec (as is)
• Global Value overwrites "no setting"
• Code specific static value overwrites global value
• Code specific dynamic value overwrites static value

it would also be nice if:

• the SDK had an way to report when the next fetch will be (wether if its a check for sentinel change or a reload)
• a event mechanism that the application could be notified that a refresh has occurred (bonus points if it provides the old/new values that were changed)
• a "force reload" mechanism

[drago-draganov]

Thanks for the suggestion, @Leonardo-Ferreira! We will look into it.

As far as diagnostics, please follow Logging and Monitoring

To detect reload of the configuration, you can use IConfiguration.GetReloadToken