Colección de residuos hace que el clúster dé el error <Error accessing the cache container - Error on PUT action for cache Local:SERVICE_FACTORY_CACHE> | AEM Forms

Colección de residuos hace que el clúster dé el error <Error accessing the cache container - Error on PUT action for cache Local:SERVICE_FACTORY_CACHE> | AEM Forms

Buscar
AEM 6.0 Forms Guía del usuario

En esta página

Se aplica a: AEM 6.0 Forms AEM 6.1 Forms AEM 6.2 Forms AEM 6.3 Forms

某些 Creative Cloud 应用程序、服务和功能在中国不可用。

Países

Reino Unido

Problema

La colección de residuos en instancias de JVM configuradas con un gran tamaño de pila puede detener el sistema y hacer que el nodo del clúster se vea forzado a salir del mismo. La siguiente excepción se visualiza en el registro:

<Feb 24, 2017 1:47:07 AM CET> <Error> <com.adobe.idp.dsc.invocation.impl.ServiceFactoryCache> <BEA-000000> <Error accessing the cache container - Error on PUT action for cache Local:SERVICE_FACTORY_CACHE>
com.adobe.livecycle.cache.CacheActionException: Error accessing the cache container - Error on GET action for cache Replicated:SystemInfoStore
at com.adobe.livecycle.cache.adapter.GemfireCacheAdapter.put(GemfireCacheAdapter.java:352)
at com.adobe.monitor.stats.SystemCacheManager.addAndUpdateStatisticsCache(SystemCacheManager.java:45)
at com.adobe.monitor.stats.SystemInfoRetrievalThread.retrieveInfo(SystemInfoRetrievalThread.java:110)
at com.adobe.monitor.stats.SystemInfoRetrievalThread.run(SystemInfoRetrievalThread.java:70)
Caused by: com.gemstone.gemfire.distributed.DistributedSystemDisconnectedException: GemFire on weform4p(GC_gBqP:2381)<v3>:23067 started at Thu Feb 23 10:27:17 CET 2017: Message distribution has terminated, caused by com.gemstone.gemfire.ForcedDisconnectException: This member has been forced out of the distributed system. Reason='did not respond to are-you-dead messages'
at com.gemstone.gemfire.distributed.internal.DistributionManager$Stopper.generateCancelledException(DistributionManager.java:782)
at com.gemstone.gemfire.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:942)
at com.gemstone.gemfire.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1060)

Entorno

AEM Forms
LiveCycle ES4 SP1

Causa

AEM Forms y LiveCycle utilizan Gemfire como mecanismo de almacenamiento en caché. Para permanecer en el clúster, cada nodo responde a las peticiones de latidos del coordinador de miembros en un plazo de 5000 ms (valor predeterminado). Si el miembro no responde después de dos peticiones de latidos cardíacos, el nodo del cluster se considera defectuoso y es forzado a salir del cluster.

Si tiene una instancia de JVM ejecutándose con un tamaño de pila grande, la Recolección de Basura Completa (GC) puede hacer que todo el sistema se detenga por unos segundos hasta que se complete la GC. Existe la posibilidad de que note un error relacionado con un alto uso de memoria en el Gestor de Trabajo, o un alto uso de CPU en el Planificador, lo que indica que faltan disparadores. El GC completo evita que Gemfire responda a los latidos del corazón y hace que el nodo Cluster se vea forzado a salir si tarda más de 2 x 5000 ms.

Resolución

El primer paso es confirmar que es el comportamiento que está experimentando al analizar las estadísticas de GC. Generar estadísticas de GC añadiendo los siguientes parámetros de JVM (el siguiente ejemplo crea un registro en el disco C:):

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=30M -Xloggc:<path to a GC log file>

Solicite los registros de GC cuando el problema vuelva a ocurrir.

Fíjese en el momento en que ocurre el problema. Muestra las siguientes líneas en el Registro:

2017-03-02T01:30:41.415+0100: 107053.338: [GC [PSYoungGen: 4957696K->143858K(3736064K)] 6633519K->3611125K(8978944K), 13.7360350 secs] [Times: user=11.54 sys=1.88, real=13.73 secs]
2017-03-02T01:36:29.568+0100: 107401.492: [GC [PSYoungGen: 3736050K->825332K(4417536K)] 7203317K->4928257K(9660416K), 10.2544810 secs] [Times: user=13.20 sys=1.38, real=10.25 secs]

Esto indica que el GC completo tardó 13,73 s y 10,28 s, por encima de dos latidos del corazón. Esto hace que el nodo del clúster se vea forzado a salir.

Hay pocas opciones para resolver el problema:

  1. Optimice la recolección GC en su sistema para asegurarse de que se complete dentro del tiempo de espera de Gemfire. Para obtener más información sobre las directrices, consulte https://www.cubrid.org/blog/how-to-tune-java-garbage-collection.
  2. Generar una papelera cuando se ejecuta GC completo y analizar qué objetos se están utilizando en gran medida. Utilícelo como base para optimizar su flujo de trabajo. 
  3. Aumente el tiempo de espera de la membresía de Gemfire a un valor lo suficientemente alto como para permitir que se complete el Full GC. Por ejemplo, el argumento de JVM a continuación aumenta el tiempo de espera a 15 s, lo que cubre la situación encontrada en los registros de GC anteriores. Para más información, consulte https://pubs.vmware.com/vfabric5/index.jsp?topic=/com.vmware.vfabric.gemfire.6.6/reference/topics/gemfire_properties.html:
“-Dgemfire.member-timeout=15000”