The Advanced Cache module is collection of advanced cache strategies to help minimize load on the server while ensuring that fresh content is served to the users. Magnolia uses Ehcache, an open source Java distributed cache. All cache data is stored in the file system. The Ehcache file system can be local to the server or network, depending on configuration.

Download

The Advanced Cache module is bundled with Magnolia and typically already installed. You can download it from our Nexus repository.

Installing

Advanced Cache is a Enterprise Edition module. It is typically already installed. Launch the Configuration app and go to /modules/advanced-cache to check.

(warning) Create a backup of your system before you install a module. Uninstalling a module is not as simple as removing the .jar file. Modules add and change configurations and may change the content. Try new modules in a test environment first. A module consists of a JAR file and may include dependent JAR files. Modules are responsible for updating their own content and configurations across versions. Be sure to keep only one version of each module and its dependencies.

To install a module:

  1. Stop the application server.
  2. Copy the module JAR files into the WEB-INF/lib directory. The location of this directory depends on the application server.
    • Tomcat: /webapps/magnoliaAuthor/WEB-INF/lib
    • JBoss: /server/default/deploy/magnoliaAuthor/WEB-INF/lib
  3. Restart the server.
  4. Go to the AdminCentral URL.
  5. Start the Web update process.
  6. Click Start up Magnolia.

Repeat the steps for each author and public instance.

Uninstalling

  1. Set cache policy in /modules/cache/config/configurations/default/cachePolicy/class back to default value info.magnolia.module.cache.cachepolicy.Default.
  2. Remove the /modules/advanced-cache node and its subnodes.
  3. Shut down Magnolia, remove the Advanced Cache module JAR (magnolia-module-advanced-cache.jar) from WEB-INF/lib and start up Magnolia again.

Caching strategies

The use of this strategies only make sense in cases where you have pages that take too long to load, i.e. pages that connect to backend systems.

Serving old content while re-caching

Using this strategy, cache is not completely cleaned on content update and entries are retained. After update, when the first request comes in, fresh cache entry generation is triggered and all further requests for the same entry are served from old cache content until the new entry is ready.

  • Set /modules/cache/config/configurations/default/cachePolicy/class to info.magnolia.module.advancedcache.ServeUntilRecachedCachePolicy
  • Set /modules/cache/config/configurations/default/flushPolicy/policies/flushAll/class to info.magnolia.module.advancedcache.NotifyFlushListeningPolicy

See also: Timestamp for last flushing

Eager re-caching

Using this strategy, cache keeps a list of the most frequently served entries. The system attempts to refresh these entries as soon as it detects an update to content. All other entries are re-cached on request. It is possible to configure the number of entries to re-cache immediately and to set the lifetime of the most served content:

  • Set /modules/cache/config/configurations/default/cachePolicy/class to info.magnolia.module.advancedcache.EagerRecacheCachePolicy.
  • Set /modules/cache/config/configurations/default/flushPolicy/policies/flushAll/class to info.magnolia.module.advancedcache.EagerRecacheFlushPolicy

By default, statistics about served pages are retained indefinitely. However, you can force the system to flush the cache after each content update. To do this:

  • Create a resetAfterUpdate property node under flushPolicy.
  • Set the value to true.

To change the number of pages to be eagerly re-cached:

  • Create an eagerRecache property node under flushPolicy.
  • Set the value to the number of top most entries in the list you wish to have eagerly re-cached on every update. By default top 100 entries are eagerly re-cached.

See also: Timestamp for last flushing

Changing waiting time

By default Magnolia waits for 10 seconds, while still serving an old version of the content, before attempting to re-cache the given entry. This timeout is controlled by the blockingTimeout property configured in the Ehcache backend. The blockingTimeout applies to the whole cache factory. If you want to change the waiting time for a particular cache policy, use the timeout property.

Change the waiting time for the default server and flush policies by adding a timeout node data with value being the number of milliseconds to wait (i.e. default value is equivalent of 10 000).

Changes to cache policies and executors are applied immediately. Setting incorrect values can render the Magnolia instance inaccessible. If this happens, try the Groovy Rescue App.

See also Cache module.

Timestamp for last flushing

The advanced flush policies update a lastUpdateTimestamp property to record the last flushing event. The timestamp allows the corresponding cache policy to identify which cache entries need to be regenerated. When you delegate cache to an advanced cache policy, create a property at a path that includes the name of your custom policy.

Example 1: Serving old content while re-caching

  • /modules/advanced-cache/config/notifyFlushListeningPolicy@lastUpdateTimeStamp (default)
  • /modules/advanced-cache/config/notifyFlushListeningPolicy/<custom_cache_name>@lastUpdateTimeStamp (custom)

Example 2: Eager re-caching

  • /modules/advanced-cache/config/eagerRecacheFlushPolicy@lastUpdateTimeStamp (default)
  • /modules/advanced-cache/config/eagerRecacheFlushPolicy/<custom_cache_name>@lastUpdateTimeStamp (custom)

where <custom_cache_name> is the name of your custom policy.

Multisite cache configuration

When content is published, the cache on the public instance is flushed to show the new content. This increases the load on the server and affects all sites in a multisite environment. You can configure multiple cache configurations to ensure that only cache entries that belong to the same subree (site) as the published content are flushed.

First, configure cache filter bypasses in /server/filters/cache to ensure that the site-specific filter listens only for changes on the defined subtree, while the default configuration listens for everything else. Everything except the requests handled by the subtree is cached.

Here's an example configuration for /mx subtree.

Node nameValue

 server

 

 filters

 

 content

 

.....

 

 cache

 

 default

 

 bypasses

 

 mx

 

 class

info.magnolia.voting.voters.URIStartsWithVoter

 pattern

 /mx

 br

 

 cacheConfigurationName

default

 class

info.magnolia.module.cache.filter.CacheFilter

 mx

 

 bypasses

 

 mx

 

 class

info.magnolia.voting.voters.URIStartsWithVoter

 not

true

 pattern

 /mx

 cacheConfigurationName

mx

 class

info.magnolia.module.cache.filter.CacheFilter

 br

 

Next, configure multiple cache configurations in /modules/cache/config/configurations:

  1. Create a new content node for each cache subtree and name it to match the filter bypass (mx in the example above). 
  2. Add an extends property and set the value to ../default.
  3. In /default/flushPolicy/policies/flushAll/class replace  FlushAllListeningPolicy with  SiteAwareFlushAllListeningPolicy .
Node nameValue

 modules

 

 cache

 

 config

 

 configurations

 

 default

 

 cachePolicy

 

 browserCachePolicy

 

 executors

 

 flushPolicy

 

 policies

 

 flushAll

 

 repositories

 

 class

info.magnolia.module.advancedcache.SiteAwareFlushAllListeningPolicy

 flushByComments

 

 class

info.magnolia.module.cache.DelegateCachePolicy

 mx

 

 extends

../default

 br

 

 uuid-key-mapping

 

 compression

 

 cacheFactory

 
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))