When Adobe made the change to begin using etc.clientlibs
as a directory, we encountered issues with some existing Dispatcher cache invalidation configurations. For certain cache files, Dispatcher may delete the file on disk when a flush is called. Directories should not get deleted and Dispatcher will drop a .stat
file within them. This .stat
file’s time stamp is what Dispatcher checks when deciding whether to update the requested cache file or not.
However, because of that pesky .
character within the name of the client library cache, the Dispatcher was fooled into thinking the cache (etc.clientlibs
) should be deleted on invalidation of any /etc
files. This caused further issues when it would attempt to recreate the directory. On the next request it could be unable to create the etc.clientlibs
directory at the file system level due to a race condition. Thus, no cached client libraries would be created, and until this was manually fixed (recreate the directory by hand), all requests would hit the Publishers.
To fix this we wrote a shell script which was triggered by the Dispatcher during invalidation. To call the script we added the following to our Dispatcher configuration:
/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"
[1]
This ran our invalidate.sh
[2] shell script every time our Dispatcher’s cache was invalidated from a Flush Agent, thus triggering a recreation of the etc.clientlibs
directory and preventing our race condition.
[1] https://gitlab.arbory.digital/arbory-digital-public/aem-dispatcher-public/blob/master/etc/httpd/conf.d/invalidate.inc#L14
[2] https://gitlab.arbory.digital/arbory-digital-public/aem-dispatcher-public/blob/master/opt/dispatcher/scripts/invalidate.sh