Dynamic Cache Class Configuration of Cache Keys

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 can be employed if cache keys predefined by the product or defined in your project shall be pulled from default cache class java.lang.Object into a dedicated cache class. This way, cache optimization can be performed without changing cache class definition in the code of CacheKey implementations.

Upgrade Information

A cache key may be put into a dedicated cache class by configuring a cache capacity for its class (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 strictly necessary to move cache keys from default cache class java.lang.Object into a dedicated cache class unless

In those cases, introducing dedicated cache classes will give you better control over eviction rate and heap consumption.

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.

(CMS-30042)

Third-Party Update: Apache Tika 3.3.0 and Transitive Dependencies

Apache Tika has been updated to version 3.3.0. As part of this change, transitive dependencies of Apache Tika have been updated.

Updated dependencies:

With this update, Tika dependencies switched from using transitive dependency org.apache.poi:poi-ooxml-lite to org.apache.poi:poi-ooxml-full (TIKA-4563). If you use the former in your own code for Studio Server, Content Feeder or CAE Feeder, consider switching to the latter to avoid duplicate classes from different JAR artifacts

If you use these libraries in project code, please check their respective release notes for changes and upgrade information.

(CMS-29980)

Support PostgreSQL 17

We now also support PostgreSQL 17. No code change was required.

PostgreSQL 17 Release Notes: https://www.postgresql.org/docs/release/17.0/

(CMS-29875)

Content Feeder Improved Performance

The Content Feeder can now use multiple threads to gather data for indexing. This can improve feeding performance significantly. The number of threads can be configured with new property feeder.content.populator-threads. The default is 1 for backwards-compatibility, but that default will be increased in future versions of CMCC. Even with the default of one thread, our tests showed improved feeder throughput.

If you set feeder.content.populator-threads to more than one thread, then FeedablePopulator implementations are called concurrently by different threads. Custom implementations must be threadsafe, and should ensure that they don’t overload used services or consume too much memory. There’s no general recommendation to increase the heap memory of the Content Feeder for multiple threads, but custom code may require more memory if called concurrently. You should check and monitor the heap memory usage of the Content Feeder, if you change the number of threads.

If the “Semantic Search” feature is enabled, and feeder.content.populator-threads is set to more than one thread, then you must also limit the number of threads that may call Apache Tika to extract text from binaries. For example, set feeder.tika.threads=2 to limit semantic search feeding to two threads.

There’s also a new option for the Content Feeder to prefetch content data from the Content Server during initial feeding. By default, no prefetching is used. See the documentation of property feeder.content.initial-feeding-prefetch-size in the Deployment Manual for details.

(CMS-29851)

Third-Party Update: Apache Zookeeper

Apache Zookeeper has been updated to version 3.9.5.

(CMS-29840)

Document Check-in on Server Import Handles Already Checked-in Documents Gracefully

When finishing content import by tool serverimport, all imported documents are checked in. Previously, this step failed if recently imported documents were checked in by other processes (user interaction in Studio or other tool) which led to errors in tool's response and left subsequent check-ins unfinished. This is now changed, so that already checked-in documents no longer provoke an error.

(CMS-27210)