When customizing the Cache module configuration or using an advanced caching strategy, it can be helpful to have some confirmation things are working as intended.
By turning on the debugging features of the cache module, you can verify both cache and flush events.
Cache filter
The cache filter is the entry point into cache debugging.
To see if an item is being cached, enable DEBUG using the Log Tools app or adjust the log4j2 configuration file.
The former is a transient adjustment (resets on restart), while the latter is permanent (survives the restart).
Usually, using the app is the preferred approach.
With DEBUG enabled, the CachePolicyResult is printed to the log.
Parameter
Description
behaviour
One of three values:
bypass: Skips caching. This is useful for content that can’t or shouldn’t be cached.
useCache: Retrieves the cached item from the cache and streams it to the client.
store: Stores the response in the cache for future use.
cacheName
The name of the cache being used to store the result.
The defaultPageCache is essentially the fallback cache store for requests that don’t use site-aware caching.
cacheKey
The default cache key implementation is based on the URI, server name, parameters, and request headers.
Since the server name is likely to change from server to server, copying cached items around doesn’t prevent generating cache entries.
Parameter
Description
uri
The URI of the requested resource.
This is the key used by the cache for storage and retrieval of the value stored by the cache.
The value is the HTML generated during rendering or the binary data of the requested resource.
serverName
The requested server.
locale
The requested locale.
channel
The requested channel.
Typical values are all, desktop, and mobile.
Sometimes, it can be "unresolved" if the MultiChannelFilter can’t determine the channel.
params
Any parameters passed as part of the request.
secure
Indicates if the request was made over a secure connection.
method
The request method. POST, GET, PUT, DELETE, and so on.
additionalAttributes
Any other attributes passed as part of the request.
cachedEntry
Cache entry keeping the content in memory.
Stores a gzipped and non-gzipped version.
Parameter
Description
gzippedContent
Length of the gzipped content.
plainContent
Length of the plain content.
characterEncoding
Character encoding for the stored content.
contentType
Type of content being stored.
lastModificationTime
Last time the content was modified.
originalUrl
Original requesting URL.
serializableHeadersBackingList
List of serializable headers associated with the request.
statusCode
HTTP status code.
timeToLiveInSeconds
Time for how long the content should be valid.
-1 means forever.
Flush events
Cache flush events happen when content is updated.
When debugging a custom cache configuration, it can be helpful to have these flushes indicated in the log file.
This is especially helpful when using advance caching strategies like serve old content while recaching or eager recaching.
To enable the TRACE level logging for flush events use the Log Tools app or adjust the log4j2 configuration file.
Enable flush debugging
With flush debugging enabled, you see the flush event indicated in the log.
This also provides the name of the cache being flushed if you use multiple caches.
At the bottom of the page, enter the Logger name: info.magnolia.module.cache
Click Add logger config and check the entry is added to the list above at ALL level.
Site aware
Using the Advanced Cache module it’s possible to configure workspaces to be site-aware.
For site-ware caching to work properly, two configurations are required.
The mapping configuration of the site definition. Set in the Site app.
To enable the TRACE level logging for flush events use the Log Tools app or adjust the log4j2 configuration file.
Enable flush debugging
With flush debugging enabled, you’ll see the flush event indicated in the log.
This will also provide the name of the cache being flushed in the case you use multiple caches.