Problème

Lors de l'activation du contenu dans votre site AEM, les modifications s'affichent sur les instances de publication, mais pas sur le site Web réel.

Cause

De nombreuses causes sont possibles et varient selon l'architecture.

Les causes peuvent être :

  • Si vous utilisez un réseau de distribution de contenu :
    • Paramètres de délai d'activation incorrects.
    • En-têtes de cache erronés ou manquants (gestion de la mémoire cache, Pragma Expires)
  • Le dispatcher ou le serveur Web échoue ou est mal configuré

Résolution

La première étape pour corriger ce problème consiste à isoler le problème. Nous savons déjà que les instances de publication AEM sont mises à jour avec les activations. Le problème doit donc résider dans la pile ascendante Web, y compris le CDN et le cache du serveur Web ou du dispatcher.

I. Vérifier les serveurs Web ou les dispatchers pour voir si le contenu est obsolète.

 

  1. Si le contenu des dispatchers n'est pas obsolète, c'est que le problème réside dans les configurations TTL CDN ou dans les en-têtes envoyés par le dispatcher et AEM.  Suivre la section « II. Problèmes de CDN » ci-dessous à titre indicatif.

  2. Si les dispatchers ont un contenu obsolète, un élément est mal configuré ou fonctionne mal sur l'un de ces dispatchers.  Suivez la section « IV. « Problèmes de cache du dispatcher » à titre indicatif.

II. Problèmes de CDN

Si le contenu sur le CDN n'est pas à jour, vous pouvez essayer ce qui suit :

  1. Connectez vous à l'interface management de CDN et vérifier les configurations TTL. Si les TTL sont définis lors de la configuration de CDN, assurez-vous de ne pas les configurer trop haut.

  2. Accédez au contenu directement par le biais du dispatcher et vérifiez l'existence de titres HTTPs relatifs au cache, comme Cache-control : max-age, Expires et Pragma. Par exemple : http://dispatcher-host1/content/geometrixx/en.html.

  3. Test évitant le dispatcher en ajoutant une chaîne de requête à l'URL, par exemple http://dispatcher-host1/content/geometrixx/en.html?bypasscache=1. Testez les en-têtes liées au cache pour cette réponse également.  Les en-têtes renvoyés par une réponse sous cache peuvent différer. Notez qu'après une purge de cache du dispatcher, la première réponse HTTP sera la même qu’en évitant le dispatcher. En conséquence, certains serveurs périphériques de réseau de distribution de contenu recevront une réponse qui n'est pas passée par le dispatcher et d'autres la réponse en cache du dispatcher.

Remarque :

Si les en-têtes liés au cache sont exclus de la réponse HTTP, certains réseaux de distribution de contenu tels qu’Amazon Cloudfront mettront la réponse sous cache indéfiniment (si aucun délai d'activation n'est défini). 

III. Agent de purge bloqué ou non configuré :

Si vous avez déterminé que le problème ne se trouvait pas au niveau du réseau de distribution de contenu, l'étape suivante consiste à vérifier les configurations de l'agent de purge AEM.

Assurez-vous d'avoir configuré les agents de purge et qu'ils sont activés.

Vérifier les files d'agents de purge si les tâches de purge sous cache sont en cours de traitement ou coincées dans la file.

  1. 1. Blocage de l'agent de purge
    : si la page de l'agent de purge du dispatcher est en état bloqué, il peut y avoir un problème de connectivité réseau entre AEM et le(s) serveur(s) du dispatcher.  Assurez-vous que toutes les instances AEM avec des agents de purge configurés peuvent atteindre les serveurs du dispatcher. Modifiez les règles de pare-feu si nécessaire pour activer la connectivité entre les serveurs.

  2. 2. L'agent de purge est en état actif avec un grand nombre de tâches en attente :
    si l'agent est en état actif mais avec de nombreuses tâches, il a pu se produire :
    a. Une erreur lors de la purge
    b. Le serveur web répond extrêmement lentement aux demandes de purge
    c. Ou il existe un problème au niveau du traitement des tâches par AEM

  3. 3. L’agent de vidage est à l’état actif sans travaux en attente.
    Si l'agent affiche l'état actif mais qu’il n’y a pas de tâches en attente, le serveur web renvoie une réponse 200 pour les demandes de vidage mais n’effectue pas en fait de vidage.

IV. Problèmes de cache du dispatcher

  1. Tester une demande de vidage manuelle du dispatcher en utilisant cURL

    Testez une demande de vidage du dispatcher à l'aide de cURL. Si vous obtenez autre chose qu’une réponse 200 avec le corps de réponse « OK », le vidage du dispatcher n’est pas traité par le module dispatcher. Suivez les étapes ci-dessous pour le déboguer. 

    curl -v -H "CQ-Action: Activate" \ 
         -H "CQ-Handle: /content/bar" \ 
         -H "Content-Length: 0" \
         -H "Content-Type: application/octet-stream" \ 
         http://dispatcher-server-hostname:port/dispatcher/invalidate.cache
  2. Vérifiez la configuration dispatcher.any

    Vérifiez les allowedClients

    Vérifiez la configuration de vos /allowedClients du dispatcher configurés dans toutes les configurations du dispatcher. Assurez-vous que l'adresse IP de toutes les instances AEM conçues pour émettre des requêtes de purge sont répertoriées. 

  3. Vérifiez la configuration du serveur web.

Microsoft IIS:

A. Cochez la case « filtrage de requête ».

  1. Connectez-vous au serveur IIS par la RDP en tant qu'administrateur

  2. Ouvrez le Gestionnaire du serveur => Rôles => Gestionnaire IIS

  3. Dans le Gestionnaire IIS, naviguez jusqu'au site activé du dispatcher AEM

  4. Ouvrez Demande de filtrage

  5. Assurez-vous que les configurations de filtrage ne bloquent pas les requêtes GET et POST à /dispatcher/invalidate.cache

Reportez-vous à la documentation Microsoft pour plus d’informations sur l’accès à ces configurations et leur modification.

B. Vérification des règles de réécriture IIS

  1. Connectez-vous au serveur IIS via RDP en tant qu’administrateur

  2. Ouvrez le Gestionnaire de serveur => Roles => IIS Manager

  3. Dans le Gestionnaire des services Internet, accédez au site compatible AEM Dispatcher

  4. Ouvrez URL Rewrite

  5. Examinez les règles pour déterminer si certaines peuvent bloquer ou interrompre les requêtes GET ou POST dans /dispatcher/invalidate.cache

Consultez la Documentation de Microsoft pour plus d'informations sur la façon d'accéder à ou de remplacer ces configurations.

Serveur web Apache :

A. Vérifiez les configurations de RewriteRule.

Examinez les directives de RewriteRule dans les configurations HTTPD pour valider si certaines pourraient bloquer ou supprimer des demandes GET ou POST au /dispatcher/invalidate.cache.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne