Beaucoup d’entre nous ont pu rencontrer la situation où le dispatcher utilise une ancienne version du code. Cet article décrit comment éviter cela tout en tirant parti des possibilités de mise en cache du dispatcher.
L’invalidation est un mécanisme permettant d’identifier les ressources mises en cache obsolètes. Il existe des outils pour l’invalidation automatique et l’invalidation manuelle. Définissons la configuration initiale pour la section d’invalidation du fichier de configuration du dispatcher, puis apprenons comment l’invalidation fonctionne à bas niveau, et enfin, revenons à l’analyse des outils d’invalidation. Mais commençons par les bases.
Qu’est-ce que le cache Dispatcher dans AEM ?
Le Dispatcher est l’outil de mise en cache et d’équilibrage de charge d’AEM qui stocke les fichiers mis en cache sur le serveur web de la même manière qu’un site web statique. Une fois demandé, un document cacheable est vérifié par le Dispatcher pour identifier si ce document existe dans le système de fichiers du serveur web :
- Si le document est mis en cache, le Dispatcher renvoie le fichier.
- Le Dispatcher demande le document à l’instance AEM s’il n’est pas mis en cache.
Servir les données depuis le cache du Dispatcher réduit la charge sur les instances de publication AEM.
/cache
{
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
}
}
Comment vider le cache du Dispatcher ?
Il existe au moins 3 façons de vider le cache du Dispatcher :
- Par les agents de vidage sur l’auteur et/ou sur les instances de publication
- Vidage manuel
- Code personnalisé pour effectuer le vidage par programmation
Paramètres initiaux de la section d’invalidation
Passons maintenant à l’invalidation des pages mises en cache depuis AEM. Le bloc /invalidate à l’intérieur de la section /cache détermine les fichiers mis en cache qui peuvent être automatiquement invalidés lorsque le contenu est mis à jour. Par exemple, la configuration suivante invalide toutes les pages HTML :
/cache
{
/invalidate
{
/0000 { /glob "*" /type "allow" }
}
}
Avec l’invalidation automatique, le dispatcher ne supprime pas les fichiers mis en cache après la mise à jour du contenu, mais vérifie leur validité lors de leur prochaine demande. Les documents du cache qui ne sont pas auto-invalidés resteront dans le cache jusqu’à ce qu’ils soient supprimés lors des mises à jour de contenu. Pour citer un exemple, permettons que tout le cache soit invalidé automatiquement :
Redémarrez le serveur httpd après la mise à jour de la section /invalidate pour que les nouvelles modifications soient prises en compte.
Invalidation en détail
Le Dispatcher utilise par défaut des fichiers vides spéciaux nommés “.stat” au niveau le plus bas. Le paramètre /statfileslevel « 0 » est défini par défaut, ce qui signifie qu’un seul fichier stat, situé à la racine du dossier htdocs, est utilisé. Si l’heure de modification du fichier stat est ultérieure à l’heure de modification de la ressource, le dispatcher considère cette ressource comme obsolète ou invalide.
Par exemple, nous avons ces ressources mises en cache après avoir demandé la page http://localhost/content/geometrixx/en/products.html :
Invalidons-les en appliquant un mécanisme de fichier stat de bas niveau. Créez un fichier vide nommé « .stat » à la racine de votre répertoire htdocs :
Vous pouvez constater que l’heure de modification du fichier stat est ultérieure à l’heure des ressources mises en cache. Pour le dispatcher, cela signifie que toutes les ressources sont périmées. Il s’agit d’un mécanisme d’invalidation de bas niveau. Si nous visitons à nouveau http://localhost/content/geometrixx/en/products.html après avoir créé ce fichier stat, les ressources mises en cache demandées seront mises à jour :
Cet exemple illustre un modèle d’invalidation avec le paramètre par défaut /statfileslevel « 0 ». Voyons comment nous pouvons affiner l’invalidation plus en détail avec le paramètre /statfileslevel.
Configuration de /statfileslevel
Vous pouvez utiliser les propriétés /statfileslevel du fichier de configuration du dispatcher pour invalider sélectivement les fichiers mis en cache en fonction de leur chemin. Voici quelques règles concernant le mécanisme des propriétés /statfileslevel :
- Le dispatcher crée des fichiers .stat dans chaque dossier, en commençant par le docroot et jusqu’au niveau que vous spécifiez. Le niveau du dossier docroot est 0.
- Lorsque vous mettez à jour un fichier, le dispatcher trouve un dossier situé au niveau statfileslevel et invalide tous les fichiers de ce dossier ainsi que tous les fichiers qui se trouvent en dessous dans ce dossier.
- Si le niveau du fichier mis à jour est inférieur au statfileslevel, alors seuls les fichiers du dossier contenant le fichier mis à jour sont désactivés, mais les fichiers situés en dessous dans ce dossier restent valides.
- Lors de la mise à jour d’un fichier, tous les fichiers du dossier correspondant et des niveaux supérieurs, jusqu’au niveau racine inclus, deviennent invalides.
Examinons quelques exemples pour mieux comprendre les règles de la propriété /statfileslevel. Notre cas de démonstration par défaut, où /statfileslevel est « 0 », se présente comme suit :
Il n’y a qu’un seul fichier stat dans le dossier racine du docroot. Et la zone de responsabilité ou la portée de ce fichier stat sera l’arborescence complète des fichiers de notre docroot. Si un fichier de l’arborescence a une date de modification antérieure à celle du fichier stat, le dispatcher considérera ce fichier comme invalide.
Si nous définissons /statfileslevel à « 4 », l’invalidation fonctionne comme suit :
Des fichiers stat existent à tous les niveaux de 0 (racine) à 4.
Un fichier stat à un niveau inférieur à 4 a une portée ou une zone de responsabilité uniquement pour le dossier qui le contient. Si un fichier stat à l’intérieur du dossier content/geometrixx/en est plus récent que n’importe quel fichier de ce dossier, alors ce fichier est invalide, mais tous les fichiers d’autres dossiers sont définis par d’autres fichiers stat.
Seuls les fichiers stat ayant la valeur statfileslevel (dans notre cas, le niveau est 4) ont la portée ou la zone de responsabilité de toute l’arborescence sous-jacente, à partir du dossier contenant un tel fichier stat et s’étendant jusqu’aux niveaux inférieurs de l’arborescence des fichiers.
Ainsi, si un fichier stat à l’intérieur du dossier content/geometrixx/en/products a une heure de modification plus récente que n’importe quel fichier de l’arborescence sous-jacente, qui inclut le dossier products, le dispatcher considère ce fichier comme invalide. La validation de tous les fichiers qui ne sont pas dans cette arborescence est déterminée par d’autres fichiers stat.
Invalidation automatique et agent de vidage du Dispatcher AEM
Pour automatiser l’invalidation, vous pouvez activer des agents de vidage (flush-agents) d’auteur ou de publication. Nous recommandons d’utiliser l’agent de vidage de publication pour une invalidation automatique plus fiable, car l’utilisation de l’agent de vidage d’auteur peut entraîner les problèmes suivants :
- Le Dispatcher doit être accessible au serveur AEM de l’auteur. Si votre réseau (par exemple, à cause d’un pare-feu) est configuré de manière à ce que l’accès entre les deux soit refusé, l’invalidation automatique ne fonctionnera pas.
- La publication et l’invalidation du cache se produisent simultanément. Un utilisateur peut demander une page immédiatement après qu’elle ait été supprimée du cache mais avant que la page n’ait été publiée. Dans cette situation, AEM renvoie l’ancienne page, et le Dispatcher la met de nouveau en cache et la considère comme valide. Ce problème affecte principalement les grands sites.
L’agent de vidage de publication se trouve à l’adresse : http://localhost:4503/etc/replication/agents.publish/flush.html
Pour activer votre agent de vidage de publication, cliquez sur le bouton « Modifier », et cochez la case « Activé » :
Mettez à jour le port URI dans l’onglet Transport et définissez sa valeur à 80 :
Enregistrez vos mises à jour, et vous verrez que l’agent de vidage de publication est activé :
Requêtes d’invalidation manuelles
Vous pouvez envoyer les requêtes suivantes pour invalider manuellement vos ressources mises en cache :
- pour supprimer les fichiers mis en cache
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0
- pour supprimer et remettre en cache les fichiers
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
Content-Type: text/plain
CQ-Handle: path-pattern
Content-Length: numchars in bodypage_path0
Page_path1
…
Page_pathn
Résumé
En conséquence, nous avons pu découvrir comment ces éléments fonctionnent :
- Mécanisme d’invalidation de bas niveau ;
- Agents de vidage pour l’invalidation automatique après la publication des pages ;
- Requêtes d’invalidation manuelles.
Une documentation plus détaillée et utile est disponible sur les pages suivantes :
http://docs.adobe.com/docs/en/dispatcher/disp-config.html
http://docs.adobe.com/docs/en/dispatcher/page-invalidate.html
FAQ
Comment vider le cache Dispatcher dans AEM ?
Il existe au moins 3 façons de vider le cache Dispatcher dans AEM :
- Par les agents de vidage sur l’auteur et/ou sur les instances de publication
- Vidage manuel
- Code personnalisé pour effectuer le vidage par programmation
Qu’est-ce que le cache Dispatcher dans AEM ?
Le Dispatcher est un outil de mise en cache et d’équilibrage de charge d’AEM qui stocke les fichiers mis en cache sur le serveur web de la même manière qu’un site web statique.
Comment vérifier les journaux du Dispatcher dans AEM ?
Les journaux du Dispatcher sont gérés dans la configuration du module Dispatcher. Selon votre configuration, il peut s’agir d’un fichier .conf distinct dans /etc/httpd/conf.d ou dans le même fichier que la configuration du vhost du Dispatcher.
Quelle est la différence entre le vidage du cache (flush) et l’invalidation dans AEM ?
Selon la documentation, le vidage (flush) et l’invalidation signifient la même chose.
“Pour invalider (ou vider) le cache du Dispatcher sans activer de page, vous pouvez envoyer une requête HTTP au Dispatcher.”
Mais on peut dire que l’invalidation est un appel HTTP au Dispatcher pour marquer la ressource mise en cache comme invalide (la même chose se produit lorsque le TTL de la ressource expire). Tandis que le vidage (flush) signifie généralement une invalidation déclenchée depuis l’instance Auteur/Publication lorsque le contenu est publié.
