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
