Problème

L'interruption normale du processus de Java AEM prend trop de temps (plus de 10 minutes).

Environnement

Cause

De nombreux éléments peuvent entraîner un ralentissement de l'arrêt de AEM. Lors de l'arrêt du processus Java AEM, un lien Java s'exécute pour arrêter le conteneur Apache Felix OSGi dans lequel AEM se lance. Lors de la fermeture du conteneur OSGi, le système arrête tous les regroupements et composants OSGi. Lors de ce processus, différents services terminent les opérations d’écriture, ferment les fichiers gérés et attendent que toutes les demandes HTTP actives soient résolues.
 
Les causes les plus fréquentes des fermetures lentes sont les suivantes :

  • La méthode de désactivation d’un composant OSGi prend beaucoup de temps.
  • Des requêtes d’exécution prennent du temps lorsque le système est arrêté

Résolution

Pour résoudre un problème de fermeture lente, vous devez analyser les thread dumps pour identifier les images mémoire de threads qui la précèdent.

Procédez comme suit :

  1. Consulter les images mémoire de threads en suivant les étapes indiquées dans cet article

  2.  Ouvrir les images mémoire de threads dans un programme d'analyse tel que TDA, http://fastthread.io/ ou IBM Thread Analyzer

  3.  Rechercher les images mémoire de threads pour les threads de requête HTTP dans l’état RUNNABLE avec des noms tels que les fils ci-dessous :

    • Threads au nom commençant par « qtp » :
    "qtp1926827727-86864" #86864 prio=5 os_prio=0 tid=0x00007f320894a800 nid=0x79f0 runnable [0x00007f31d7109000]
       java.lang.Thread.State: RUNNABLE
    • Ou les threads avec un IP et une ligne de requête dans le nom :
    "10.25.10.11 [1457551498445] GET /content/dam/test.jpg HTTP/1.1" #38626 prio=5 os_prio=0 tid=0x00007fe5c854c800 nid=0x7f9c runnable [0x00007fe55f7f3000]
       java.lang.Thread.State: RUNNABLE
  4. Outre les threads de demande, recherchez le thread avec le nom « FelixStartLevel ». Ce thread traite et arrête tous les regroupements et composants OSGi. Il donne une indication de ce qui retarde l’interruption. 

    "FelixStartLevel" #18 daemon prio=5 os_prio=0 tid=0x00007f32ad8c2800 nid=0x6992 runnable [0x00007f32946d7000]
       java.lang.Thread.State: RUNNABLE
  5.  Recherchez des modèles dans la trace de pile du thread « FelixStartLevel » et les images mémoire de threads. Vérifiez s’il bloque un lot ou désactive un composant OSGi particulier sur de nombreuses images mémoire de threads. Vous pouvez utiliser un outil tel que « grep » pour analyser cette opération. Par exemple, si vous avez visionné que le composant SlingServletResolver OSGi a été désactivé à travers différentes images mémoire de threads, vous pouvez utiliser la commande ci-dessous. La commande ci-dessous indique le nombre d'images mémoire de threads ayant un fil FelixStartLevel avec SlingServletResolver dans sa trace de pile :

    grep -A 50 FelixStartLevel jstack.* | grep SlingServletResolver | awk '{print $1 }' | uniq | wc -l
  6. Une fois repéré ce qui ralentit l'arrêt, vous pouvez déterminer s’il s’agit d’un problème d’application ou non.  Si le problème est lié au code de produit AEM, contacter l'assistance clientèle AEM.

    Remarque :

    Voir cet article pour en savoir plus sur l'analyse des images mémoire de threads.

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