Coleta de lixo que causa falha no cluster com <Error accessing the cache container - Error on PUT action for cache Local:SERVICE_FACTORY_CACHE> | AEM Forms

Coleta de lixo que causa falha no cluster com <Error accessing the cache container - Error on PUT action for cache Local:SERVICE_FACTORY_CACHE> | AEM Forms

Pesquisar
AEM 6.0 Forms Guia do Usuário

Nesta página

Aplica-se a: AEM 6.0 Forms AEM 6.1 Forms AEM 6.2 Forms AEM 6.3 Forms

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

Países

Reino Unido

Problema

A coleta de lixo em instâncias do JVM configuradas com um tamanho grande de Heap pode interromper o sistema e fazer com que o nó do cluster seja forçado a sair do cluster. A seguinte exceção é exibida no campo 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

O AEM Forms e o LiveCycle usam Gemfire como um mecanismo de cache. Para permanecer no cluster, cada nó responde a solicitações de heartbeat do coordenador do membro dentro de 5000 ms (valor padrão). Se o membro não responder depois de duas solicitações Heartbeat, o nó do cluster será considerado defeituoso e será forçado a sair do cluster.

Se você tiver uma instância de JVM com um tamanho de pilha grande, a Garbage Collection completa (GC) poderá fazer com que todo o sistema seja pausado por alguns segundos até que o GC seja concluído. Há uma possibilidade de observar o erro relacionado ao uso de memória alta do Gerenciador de trabalho ou de alta utilização da CPU do agendador, indicando disparadores ausentes. O GC completo impede que o Gemfire responda a heartbeats e faz com que o nó do Cluster seja forçado se levar mais de 2 x 5000 ms.

Solução

A primeira etapa é confirmar que é o comportamento que você está encontrando analisando estatísticas de GC. Gerar estatísticas de GC adicionando os seguintes parâmetros de JVM (o exemplo a seguir cria um log na unidade C:):

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

Solicite os logs de GC quando o problema ocorrer novamente.

Examine o momento em que ocorre o problema. Ele exibe as seguintes linhas no 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]

Ele indica que o GC completo levou 13,73 s e 10,28 s, que estão acima do tempo para os dois Heartbeats. Faz com que o nó do cluster seja forçado.

Há algumas opções para resolver o problema:

  1. Otimize a coleta de GC em seu sistema para garantir que seja concluída dentro do tempo limite do Gemfire. Para obter as diretrizes, consulte https://www.cubrid.org/blog/how-to-tune-java-garbage-collection.
  2. Gere um despejo de pilha quando o GC completo for executado e analise quais objetos estão sendo usados intensamente. Use-o como base para otimizar seu fluxo de trabalho. 
  3. Aumente o tempo limite da associação Gemfire a um valor alto o suficiente para permitir que o GC completo seja concluído. Por exemplo, o argumento JVM abaixo aumenta o tempo limite para 15 segundos, o que abrange a situação encontrada nos logs de GC acima. Para obter mais informações, consulte https://pubs.vmware.com/vfabric5/index.jsp?topic=/com.vmware.vfabric.gemfire.6.6/reference/topics/gemfire_properties.html:
“-Dgemfire.member-timeout=15000”