Résolution des incidents liés à AEM

La section ci-dessous traite de certains problèmes susceptibles d’être rencontrés lorsque vous utilisez AEM, ainsi que des suggestions pour les résoudre.

Scénarios de résolution des incidents pour les administrateurs

Le tableau ci-dessous contient une présentation des incidents que les administrateurs peuvent avoir à résoudre :

Problèmes d’installation

Pour plus d’informations sur les scénarios de résolution des incidents ci-dessous, voir Problèmes d’installation fréquents :

• Un double clic sur le fichier .jar Quickstart n’a aucun effet, ou le fichier JAR est utilisé avec un autre programme (tel que le gestionnaire d’archive).
• Les applications qui s’exécutent sur CRX génèrent des erreurs de mémoire insuffisante.
• Après avoir double-cliqué sur Quickstart AEM, l’écran de bienvenue d’AEM ne s’affiche pas dans le navigateur.

Méthodes d’analyse de la résolution des incidents

Création d’une image mémoire des threads

L’image mémoire des threads est une liste de toutes les unités d’exécution Java actuellement actives. Si AEM ne répond pas correctement, l’image mémoire des threads peut vous aider à identifier des verrouillages ou d’autres problèmes.

Utilisation du programme d’image mémoire des threads Sling

1. Ouvrez la console Web AEM; par exemple, à http://localhost:4502/system/console/.

2. Sélectionnez l’onglet Threads sous État .

Utilisation de jstack (ligne de commande)

1. Recherchez le PID (ID de processus) de l’instance Java AEM.

   Par exemple, vous pouvez utiliser ps -ef ou jps.

2. Exécuter:

   jstack <pid>

3. L’image mémoire des threads s’affiche.

Pour plus d’informations, voir Comment utiliser les images mémoire des threads d’une machine virtuelle Java (JVM).

Contrôle des sessions JCR non fermées

Lorsque la fonctionnalité est développée pour AEM WCM, il est possible d’ouvrir des sessions JCR (cela s’apparente à l’ouverture d’une connexion de base de données). Si les sessions ouvertes ne sont jamais fermées, votre système peut rencontrer les symptômes suivants :

• Le système est ralenti.
• Vous pouvez voir beaucoup de CacheManager : resizeAll entrées dans le fichier journal ; le nombre suivant (size=<x>) indique le nombre de caches. chaque session ouvre plusieurs caches.
• Parfois, la mémoire du système est saturée (après quelques heures, jours ou semaines, selon la gravité).

Pour analyser les sessions non fermées et découvrir le code qui ne ferme pas une session, consulter l’article Analyse des sessions non fermées de la base de connaissances.

Utilisation de la console web d’Adobe Experience Manager

Le statut des lots OSGi peut également fournir une indication précoce de problèmes éventuels.

1. Ouvrez la console Web AEM; par exemple, à http://localhost:4502/system/console/.

2. Sélectionnez Lots sous l’onglet OSGI.

3. Vérifiez :

   • le statut des lots. Si le statut est Inactif ou Insatisfait, essayez d’arrêter et de redémarrer le lot. Si le problème persiste, un examen plus approfondi peut être nécessaire à l’aide d’autres méthodes.
   • Si l’un des lots possède des dépendances manquantes. Ces informations peuvent être affichées en cliquant sur le nom de chaque lot, qui est un lien (l’exemple ci-dessous ne comporte aucun problème) :