Currently, like the FileStorage and the MsSqlServerSrorage, the Reporting service performs periodic clean ups of the cachec client assets in the RedisStorage.

Those assets are stored in keys, which do not have an expiration date, so the Reporting service is the one that is single-handedly responsible for deleting those keys.

This approach may work well for the other storages, but in terms of Redis, it leaves more to be desired. Some of the possible cons of this approach are that:

1. Cleanup depends on traffic. Expired report data is removed only when a new viewer client registers. If the service stops getting viewer traffic, nothing it stored is ever removed.
2. Upgrades leave data behind. The storage keys include the Telerik product version. After an upgrade, the service only looks at keys for the new version, so cleanup never reaches data written by the previous version. It stays in Redis for good, no matter how much traffic the service gets.

So whether Redis memory is ever reclaimed depends on viewer traffic and upgrade history. In a shared Redis cache, the leftover data builds up until the cache reaches its memory limit. Redis can't evict it, because standard eviction policies apply only to keys with an expiration. The cache then starts rejecting writes, which breaks every application using it.

A cache provider should guarantee its data expires on its own, without depending on later traffic or on cleanup code that knows about earlier versions.

Requested:
An expiration option on RedisStorage, with a sliding expiration refreshed on access. With that in place, Redis reclaims all storage on its own, including data from previous versions, regardless of viewer traffic.