Sometimes you may find that Dispatcher cache files are updated at an unexpected time or frequency. This article explains how to analyze such a situation.
AEM as a Cloud Service, AEM 6.5
Upon publishing content, AEM sends a cache invalidation request (GET /dispatcher/invalidate.cache) to the Dispatcher. After that, when a request for the content comes to the Dispatcher, it updates its cache files.
Based on this behavior, look for a pattern by collecting the logs about the cache invalidation requests and the content requests.
Example logs for an invalidation request:
Dispatcher - access_log
127.0.0.1 - - 07/Jun/2022:13:44:35 +0900 "GET /dispatcher/invalidate.cache HTTP/1.1" 200 13 "about:blank" "Jakarta Commons-HttpClient/3.1"
Dispatcher - dispatcher.log
07/Jun/2022:13:44:35 +0900 "GET /dispatcher/invalidate.cache HTTP/1.1" 200 purge publish/- 0ms
Publish - error.log
07.06.2022 13:44:35.750 *INFO* sling-threadpool-f158f7aa-d59d-4d34-9bfa-be84a03a917f-(apache-sling-job-thread-pool)-1-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush) com.day.cq.replication.Agent.flush Sending GET request to http://localhost:80/dispatcher/invalidate.cache ... 07.06.2022 13:44:35.758 *INFO* sling-threadpool-f158f7aa-d59d-4d34-9bfa-be84a03a917f-(apache-sling-job-thread-pool)-1-com_day_cq_replication_job_flush(com/day/cq/replication/job/flush) com.day.cq.replication.Agent.flush Replication (ACTIVATE) of /content/we-retail/us/en/products successful.
Here are typical cases where the Dispatcher cache files are updated unexpectedly.
Case 1 - Frequent cache updates for unexpected contents
Cache files are updated frequently, but the updated contents are not the target of the cache invalidation request.
In this case, the value of /statfileslevel in the Dispatcher configuration may be too low. Note that commenting out /statfileslevel in dispatcher.any means “0” for this value.
When you have /statfileslevel “0” and publish content, all the cache files are invalidated regardless of the paths. The reference describes the detail.
Case 2 - Cache invalidation requests from an undesired client
The Dispatcher configuration may not have an appropriate restriction for cache invalidation requests. Check /allowedClients in dispatcher.any.
Case 3 - No cache invalidation requests
The Dispatcher configuration may use time-based cache invalidation. In this case, /enableTTL “1” should exist in dispatcher.any.