La page d’accueil ne se charge pas avec du contenu sur Adobe Experience Manager
AEM as a Cloud Service diffuse par intermittence une page d’accueil vierge, ce qui perturbe l’expérience utilisateur et déclenche de fausses alertes de temps d’arrêt. Ce problème est souvent dû à une mise en cache prématurée, à des services non initialisés ou à des erreurs de rendu. Cet article explique comment corriger ce problème en ajustant les règles de cache, en examinant le comportement de préchauffage et en ajoutant des contrôles d’intégrité pour les composants personnalisés afin de garantir une diffusion de contenu fiable.
Description description
Environnement
Ce problème affecte Adobe Experience Manager (AEM) as a Cloud Service - Sites, en particulier dans l’environnement de production.
Problème/Symptômes
La page d’accueil se charge sans contenu par intermittence, renvoyant une page vide. Les outils de surveillance génèrent plusieurs alertes indiquant le temps d’arrêt de la page d’accueil. Bien que le problème se résolve dans les 10 à 20 minutes, il se répète fréquemment. Pendant ces périodes, l’analyse affiche les incohérences de taille de page et le système met en cache les versions de la page vide.
Résolution resolution
Procédez comme suit pour résoudre ce problème :
-
Configurez des règles d’invalidation du cache appropriées pour empêcher la diffusion de contenu obsolète ou incohérent. Incluez
localhostou127.0.0.1commeServerAliasdans votre configuration d’hôte virtuel pour l’invalidation du Dispatcher. Pour plus d’informations, consultez les sections Présentation de la mise en cache du Dispatcher et Pages mises en cache invalidées à partir d’AEM. -
Désactivez temporairement le service de préchauffage s’il envoie des requêtes avant l’initialisation de tous les services, ce qui peut entraîner la mise en cache de pages incomplètes.
-
Effectuez la mise à niveau vers la dernière version d’AEM pour appliquer des correctifs qui résolvent les problèmes où les erreurs de rendu entraînent des valeurs nulles mises en cache.
-
Examinez et mettez à jour les modèles Sling dans votre base de code (pour plus d’informations, voir Création d’un modèle Sling pour le composant) :
- Ne marquez les injections que comme facultatives, si nécessaire.
- Gérer explicitement les valeurs nulles dans le code pour éviter les exceptions d’exécution lors de l’initialisation.
-
Implémentez des contrôles d’intégrité OSGi pour les composants personnalisés critiques afin de vous assurer qu’ils sont initialisés avant la diffusion du trafic
code language-none { "hc.name": "Required Custom Components", "hc.tags": [ "systemalive", "systemready"] , "components.list": [ "com.example.core.services.impl.RenditionServiceImpl"] }Testez cette configuration localement en accédant à
/system/console/healthcheck?tags=systemreadyet en confirmant que tous les composants répertoriés renvoient un statut OK. Pour plus d’informations, voir Configuration d’OSGi pour AEM as a Cloud Service. -
Consultez les journaux de pod au démarrage pour identifier les exceptions liées au rendu des échecs ou des services non initialisés (par exemple,
NullPointerException). Corrigez ces problèmes en assurant une injection et une initialisation correctes des dépendances. -
Testez toutes les modifications dans les environnements d’évaluation avant le déploiement en production afin de réduire le risque de temps d’arrêt ou de problèmes de mise en cache.
Ces étapes vous permettent d’éviter les pannes récurrentes de la page d’accueil et d’assurer une diffusion cohérente du contenu en traitant les causes profondes telles que les erreurs d’initialisation du service et les configurations de mise en cache incorrectes.