CoreMedia Cache Keys that are not specified for a dedicated cache class are stored in default cache class java.lang.Object. This could

With a revised assignment of cache keys to classes, dynamic cache class lookup by key type, and introduction of heap memory consumption estimation for some cache keys, it is know possible to optimize cache behavior by making it more predictable. This requires reviewing and maybe adjusting some of your project’s existing cache class settings.

Upgrade information

If no specific cache class is defined via CacheKey#cacheClass(Cache, T), lookup of a cache class for the cache key is now done by traversing the type hierarchy against the configured capacities of a cache. See Java documentation for com.coremedia.cache.CacheKey#cacheClass(Cache, T) and com.coremedia.cache.Cache#cacheClassFor(Class<?>). This mechanism may be relevant for you to pull cache keys predefined by the product or defined in your project from default cache class java.lang.Object into a dedicated cache class. See last section in this upgrade information for predefined cache keys that may be subject to this step. You can use actuator endpoint http://<host>:<management-port>/actuator/cache/java.lang.Object?keys=true to get information about cache keys that are currently stored in the default cache class.

As the cache class assignments for some cache keys have changed, it is strongly recommended to check your project’s individual cache capacity settings when upgrading by comparing eviction rates of the current system with the upgraded system. Preferably, use a load test which processes the majority of your sites' data. Check for eviction rates in cache classes com.coremedia.cap.heap and contenthub.object (if a ContentHub Adapter is active in your system). Neither should be increased. Also check for changes in Java heap memory consumption and GC timings. Neither should be increased. Adjust cache capacity for com.coremedia.cap.heap, contenthub.object, and/or Java maximum heap accordingly. Ideally, use a monitoring tool to gain insights. Alternatively, you can retrieve the information via actuator endpoint /actuator/prometheus. The following entries in the delivered metrics are relevant for an investigation:

The following cache keys have been equipped with memory size estimations and are now stored in cache class “com.coremedia.cap.heap“:

The following cache keys have been moved to dedicated cache classes. As they don’t vary noticeably in memory size they don’t require a memory estimation:

This leaves the following cache keys without dedicated cache classes. Without further configuration, they are stored in cache class java.lang.Object:

Those cache keys may be put into dedicated cache classes by configuring a cache size for each (see Java documentation for com.coremedia.cache.CacheKey#cacheClass(Cache, T) and com.coremedia.cache.Cache#cacheClassFor(Class<?>)). Example: if a dedicated cache class shall be defined for cache key com.coremedia.blueprint.cae.view.resolver.ThemeTemplateViewRepositoryProvider$TemplateLocationsCacheKey, add the following line (with appropriate capacity for your project) to the Spring configuration of your CAEs:

cache.capacities.com.coremedia.blueprint.cae.view.resolver.ThemeTemplateViewRepositoryProvider.TemplateLocationsCacheKey=100

However, it is not recommended to move the before-mentioned predefined cache keys from cache class java.lang.Object into a dedicated cache class unless a high eviction rate is observed and the cache capacity cannot be increased. For project-specific cache keys, an estimation of memory size may prove helpful if Java heap consumption by those cache keys is high or varying widely.

(CMS-27132)