Adobe AEM (CQ) 5.6.1: Cutting Down on Dispatcher Flush Agents
Having multiple domains / virtual hosts on an Adobe AEM Dispatcher with an AEM Publish instance would require a multitude of Dispatcher Flush agents but you can cut them down to one per Dispatcher / Apache Server. This can be done but there is a pitfall to be handled.A traditional Apache Server / Dispatcher configuration with multiple virtual hosts would require one Dispatcher Flush Replication Agent per Virtual Host. But this can be cut down to one if all cache folders are placed in the same parent folder with that:
- Create a Virtual Host that has the parent folder of the dispatcher cache folders as document root and uses the Dispatcher like the others
- Create a Farm Entry inside the Dispatcher Configuration (dispatcher.any) having the same Virtual Host and Document Root as defined in 1.
- Set the /statfileslevel to 1 so that a .stat file is created in the parent folder but also in all cache folders of the other virtual hosts
- Create a Dispatch Flush Replication Agent that has a Transport URI that points to the Virtual Host defined in 1.
Even though this works and is documented in Adobe’s dispatcher configuration documentation it does only work if no ETC Mapping is used in AEM. So if you map /content/domain1/en/home.html to /home.html then this approach will not work because the incoming path of /content/domain1/en/… of the updated resource is not matching your cached path of /….
The solution is simple but one has to know. So instead of setting the /statfileslevel to 1 one has to create a shell script like invalidate.sh and add that as the /invalidateHandler entry to the Cache section of the dispatcher configuration. The shell script can look like this:
#!/bin/bash # Invalidate the First Cache Folder touch /path/to/cache1/folder/.stat # Invalidate the Second Cache Folder ...
That script receives 3 parameters:
- Handle: content path of what is invalidated
- Action: if the content was activated or deactivated
- Action Scope: normally empty
For most part you can ignore the parameters because the script updates the .stat file marking all files in the cache as invalid. In case you want also to delete a file from the cache in a deactivation you must keep in mind that you need to apply the ETC Mapping to the content path otherwise you will not find the file.
Please remember that you need to test your environment before going life and to easily see if the .stat files are updated as expected you can mimic the Dispatcher Cache Flush by executing a CURL command using the Dispatcher Flush’s Transport URI and the headers defined there as well. Keep in mind that the Action must be Activate (or Deactivate) and not Test as indicated when you test the connection in the Dispatcher Flush Agent. A CURL command could look like this:
curl -H "CQ-Action: Activate" -H "CQ-Handle: /content/domain1/..." -H "CQ-Path:/content/domain1/..." -H "Content-Length: 0" -H "Content-Type: application/octet-stream" http://localhost:80/dispatcher/invalidate.cache
Afterwards you know that the cache is invalidated correctly in the Dispatcher and can start testing the cache invalidation through page activation / deactivation.
Cheers – Andy