La section suivante décrit certains problèmes que vous pouvez rencontrer lors de l’utilisation d’AEM, ainsi que des suggestions pour les résoudre.
Si vous résolvez les problèmes liés à la création dans AEM, reportez-vous à la section Résolution des problèmes pour les auteurs.
En cas de problème, il est également intéressant de consulter la liste des Problèmes connus pour votre instance (Service Packs et version).
Le tableau suivant présente un aperçu des problèmes que les administrateurs peuvent résoudre :
Rôle | Problème |
Administrateur système | Double-cliquer sur le fichier JAR Quickstart n’a aucun effet ou ouvre le fichier JAR avec un autre programme (par exemple, le gestionnaire d’archives). |
Administrateur système |
Mon application qui s’exécute sur CRX génère des erreurs de mémoire insuffisante. |
Administrateur système |
Après avoir double-cliqué sur Quickstart CM AEM, l’écran d’accueil d’AEM ne s’affiche pas dans le navigateur |
Administrateur système utilisateur administrateur |
Création d’une image mémoire des threads |
Administrateur système utilisateur administrateur |
Contrôle des sessions JCR non fermées |
Voir Problèmes d’installation courants pour plus d’informations sur les scénarios de dépannage suivants :
Le thread dump est une liste de tous les threads Java™ actuellement principaux. Si AEM ne répond pas correctement, le thread dump peut vous aider à identifier les blocages ou d’autres problèmes.
https://localhost:4502/system/console/
.Recherchez le PID (ID de processus) de l’instance Java™ AEM.
Vous pouvez, par exemple, utiliser ps -ef
ou jps
.
Exécutez :
jstack <pid>
Affiche le vidage des threads.
Vous pouvez ajouter les images mémoire des threads à un fichier journal en utilisant la redirection de sortie >>
:
jstack <pid> >> /path/to/logfile.log
Pour plus d’informations, consultez la section Comment utiliser les images mémoire des threads d’une machine virtuelle Java (JVM).
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 présenter les symptômes suivants :
Pour analyser les sessions non fermées et déterminer le code qui ne ferme pas une session, reportez-vous à l’article de la base de connaissances Analyse des sessions non fermées.
L’état des lots OSGi peut également donner une indication précoce des problèmes possibles.
Ouvrez le Console web d’AEM; par exemple, à l’adresse https://localhost:4502/system/console/
.
Sélectionnez Lots dans l’onglet OSGI.
Vérifier :