Problema

Detener el proceso de java de AEM está llevando demasiado tiempo (más de 10 minutos).

Entorno

Causa

Puede haber muchas cosas que pueden causar que el apagado del AEM tome mucho tiempo. Cuando se detiene el proceso java AEM, ejecuta un gancho java para apagar el contenedor Apache Felix OSGi en el que se ejecuta el AEM. Durante el cierre del contenedor OSGi, el sistema detiene todos los paquetes y componentes de OSGi. Como parte de ese proceso, varios servicios terminan las operaciones de escritura, cierran el manejo de archivos abiertos y esperan hasta que se respondan todas las peticiones HTTP activas.

Las causas más comunes de los apagados lentos son:

  • El método de desactivación para un componente de OSGi tarda mucho tiempo en ejecutarse
  • Cuando el sistema está apagado, se producen solicitudes de larga duración

Resolución

Para solucionar un problema de cierre lento, es necesario analizar los subprocesos para averiguar cuáles están retrasando el cierre.

Siga estos pasos:

  1. Realice volcados de subprocesos siguiendo los pasos de este artículo

  2.  Abra los volcados de subprocesos en un analizador de descargas de subprocesos como TDAhttp://fastthread.io/, o IBM Thread Analyzer

  3.  Busque en los volcados de subprocesos las peticiones HTTP en estado Ejecutable con nombres como los de abajo:

    • Subprocesos que empiezan con "qtp" en el nombre:
    "qtp1926827727-86864" #86864 prio=5 os_prio=0 tid=0x00007f320894a800 nid=0x79f0 runnable [0x00007f31d7109000]
       java.lang.Thread.State: RUNNABLE
    • O subprocesos con IP y línea de solicitud en el nombre:
    "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. Además de los subprocesos de solicitud, busque el subproceso con el nombre "FelixStartLevel". Ese subproceso se encarga de iniciar y detener todos los paquetes y componentes de OSGi, y da indicaciones de lo que está retrasando el apagado. 

    "FelixStartLevel" #18 daemon prio=5 os_prio=0 tid=0x00007f32ad8c2800 nid=0x6992 runnable [0x00007f32946d7000]
       java.lang.Thread.State: RUNNABLE
  5.  Busque patrones en la traza de la pila del subproceso FelixStartLevel a través de los volcados de subprocesos. Vea si está atascado deteniendo un paquete o desactivando un componente particular de OSGi a través de muchos de los subprocesos. Puede utilizar una herramienta como "grep" para analizar esto. Por ejemplo, si observó que el componente SlingServletResolver OSGi se estaba desactivando en varios volcados de subprocesos, puede usar el siguiente comando. El siguiente comando cuenta cuántos volcados de subprocesos tiene el subproceso FelixStartLevel con SlingServletResolver en su traza de pila:

    grep -A 50 FelixStartLevel jstack.* | grep SlingServletResolver | awk '{print $1 }' | uniq | wc -l
  6. Una vez que averigüe qué es lo que está retrasando el apagado y determine si se trata de un problema de la aplicación o no.  Si está relacionado con el código de producto AEM, póngase en contacto con el servicio de atención al cliente de AEM.

    Nota:

    Vea este artículo para más detalles sobre el análisis del depósito de subprocesos.

Esta obra está autorizada con arreglo a la licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 Unported de Creative Commons.  Los términos de Creative Commons no cubren las publicaciones en Twitter™ y Facebook.

Avisos legales   |   Política de privacidad en línea