Garbage Collection causa il fallimento del cluster con <Error accessing the cache container - Error on PUT action for cache Local:SERVICE_FACTORY_CACHE> | AEM Forms

Garbage Collection causa il fallimento del cluster con <Error accessing the cache container - Error on PUT action for cache Local:SERVICE_FACTORY_CACHE> | AEM Forms

Cerca
AEM 6.0 Forms Guida utente

Su questa pagina

Prodotti interessati: AEM 6.0 Forms AEM 6.1 Forms AEM 6.2 Forms AEM 6.3 Forms

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

Paesi

Regno Unito

Problema

Garbage Collection su istanze JVM configurate con una Heap Size di grandi dimensioni può fermare il sistema e causare l'uscita forzata dal nodo cluster. La seguente eccezione viene visualizzata nel LOG:

<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)

Ambiente

AEM Forms
LiveCycle ES4 SP1

Causa

AEM Forms e LiveCycle utilizzano Gemfire come meccanismo di caching. Per rimanere nel cluster, ogni nodo risponde alle richieste del coordinatore membro entro 5000 ms (valore predefinito). Se il membro non risponde dopo due richieste Heartbeat, il nodo del cluster è considerato difettoso ed è costretto a uscire dal cluster.

Se si ha un'istanza di JVM in esecuzione con Heap Size di grandi dimensioni, Full Garbage Collection (GC) può causare una pausa dell'intero sistema per alcuni secondi fino al completamento del GC. C'è la possibilità che si noti un errore relativo all'uso di memoria elevata dal Work Manager, o all'uso elevato della CPU dallo Scheduler che indica trigger mancanti. Full GC impedisce a Gemfire di rispondere agli heartbeat e fa sì che il nodo cluster venga espulso se ci vogliono più di 2 x 5000 ms.

Risoluzione

Il primo passaggio è quello di confermare che si tratta del comportamento che si ipotizza analizzando le statistiche GC. Genera le statistiche GC aggiungendo i seguenti parametri JVM (l'esempio seguente crea un log sull'unità C:):

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

Richiedere i log del GC quando il problema si ripresenta.

Guarda il momento in cui si verifica il problema. Visualizza le seguenti righe nel LOG:

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]

Indica che la GC completa ha richiesto 13,73 s e 10,28 s, che sono al di sopra del tempo impiegato per i due heartbeat. Ciò provoca l'espulsione del cluster.

Sono disponibili poche opzioni per risolvere il problema:

  1. Ottimizzare la raccolta GC sul sistema per assicurarsi di completare entro il timeout di Gemfire. Per le linee guida, fai riferimento a https://www.cubrid.org/blog/how-to-tune-java-garbage-collection.
  2. Genera un Heap Dump quando viene eseguito il Full GC e analizza quali oggetti vengono utilizzati in modo massiccio. Utilizzalo come base per ottimizzare il tuo flusso di lavoro. 
  3. Aumenta il Timeout di appartenenza Gemfire di un valore abbastanza alto per consentire al GC completo di operare. Per esempio, l'argomento JVM riportato di seguito aumenta il timeout a 15 s, che copre la situazione trovata nei log GC descritti prima. Per ulteriori informazioni, fai riferimento a https://pubs.vmware.com/vfabric5/index.jsp?topic=/com.vmware.vfabric.gemfire.6.6/reference/topics/gemfire_properties.html:
“-Dgemfire.member-timeout=15000”