Scripts d'invalidation personnalisés de l'AEM Dispatcher

Lorsque Adobe a décidé d'utiliser etc.clientlibs comme répertoire, nous avons rencontré des problèmes avec certaines configurations existantes d'invalidation du cache du Dispatcher. Pour certains fichiers de cache, Dispatcher peut supprimer le fichier sur le disque lorsqu'une vidange est appelée. Les répertoires ne devraient pas être supprimés et Dispatcher déposera un fichier .stat. en leur sein. Ce .stat est ce que Dispatcher vérifie lorsqu'il décide de mettre à jour ou non le fichier de cache demandé.

Cependant, à cause de ce satané . dans le nom du cache de la bibliothèque client, le Dispatcher a été trompé en pensant que le cache(etc.clientlibs) doit être supprimé lors de l'invalidation de tout fichier /etc. Cela a causé d'autres problèmes lorsqu'il a tenté de recréer le répertoire. Lors de la requête suivante, il pourrait être incapable de créer le répertoire etc.clientlibs au niveau du système de fichiers en raison d'une condition de course. Par conséquent, aucune bibliothèque client en cache ne sera créée et, jusqu'à ce que ce problème soit résolu manuellement (recréer le répertoire à la main), toutes les requêtes se heurteront aux éditeurs.

Pour résoudre ce problème, nous avons écrit un script shell qui était déclenché par le Dispatcher pendant l'invalidation. Pour appeler le script, nous avons ajouté ce qui suit à la configuration de notre Dispatcher :

/invalidateHandler " /opt/dispatcher/scripts/invalidate.sh" [1]

Ce script shell invalidate.sh [2] est exécuté à chaque fois que le cache de notre Dispatcher est invalidé par un agent Flush, ce qui déclenche une recréation du répertoire etc.clientlibs et empêche notre condition de course.

[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

Nous contacter

Episodes du podcast