Pergunta

Usando: Hornetq 2.0.0.cr2 Configurações padrão para o servidor independente/não agrupado.

Quando tento iniciar o servidor com um grande diário (> 1 GB), obtive uma exceção da Memória:

[main] 12:59:43,505 INFO [org.hornetq.integration.bootstrap.HornetQBootstrapServer]  Starting HornetQ Server
[main] 12:59:44,526 INFO [org.hornetq.core.server.impl.HornetQServerImpl]  live server is starting..
[main] 12:59:44,532 WARNING [org.hornetq.core.server.management.impl.ManagementServiceImpl]  It has been detected that the cluster admin user and password which are used to replicate management operation from one node to the other have not been changed from the installation default. Please see the HornetQ user guide for instructions on how to do this.
[main] 12:59:44,564 WARNING [org.hornetq.core.persistence.impl.journal.JournalStorageManager]  AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
[main] 12:59:44,565 INFO [org.hornetq.core.persistence.impl.journal.JournalStorageManager]  Using NIO Journal
Exception in thread "hornetq-expiry-reaper-thread" java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.concurrent.ConcurrentHashMap.values(ConcurrentHashMap.java:1011)
at org.hornetq.core.postoffice.impl.PostOfficeImpl$Reaper.run(PostOfficeImpl.java:1083)
at java.lang.Thread.run(Thread.java:637)
[main] 13:00:17,135 SEVERE [org.hornetq.integration.bootstrap.HornetQBootstrapServer]  Failed to start server
java.lang.IllegalStateException: Incompletely deployed:

DEPLOYMENTS IN ERROR:
  Deployment "JMSServerManager" is in error due to: java.lang.OutOfMemoryError: GC overhead limit exceeded

at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.bootstrap(HornetQBootstrapServer.java:159)
at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:83)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.run(HornetQBootstrapServer.java:117)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.main(HornetQBootstrapServer.java:73)
Exception in thread "main" java.lang.IllegalStateException: Incompletely deployed:

DEPLOYMENTS IN ERROR:
  Deployment "JMSServerManager" is in error due to: java.lang.OutOfMemoryError: GC overhead limit exceeded

at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.bootstrap(HornetQBootstrapServer.java:159)
at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:83)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.run(HornetQBootstrapServer.java:117)
at org.hornetq.integration.bootstrap.HornetQBootstrapServer.main(HornetQBootstrapServer.java:73)

Isso pode acontecer na vida real quando um consumidor para de processar as mensagens e eu preciso reiniciar o servidor.

Existe alguma solução alternativa para isso? Ou quais configurações devo tentar modificar?

Foi útil?

Solução

Acontece que era simples evitar completamente esse problema.

o Paginação Não está ativado na configuração padrão!

Adicionar essas 2 linhas no Hornetq-configuration.xml deve fazer o truque:

   <address-settings>
      <!--default for catch all-->
      <address-setting match="#">
         <dead-letter-address>jms.queue.DLQ</dead-letter-address>
         <expiry-address>jms.queue.ExpiryQueue</expiry-address>
         <redelivery-delay>0</redelivery-delay>
         <page-size-bytes>10485760</page-size-bytes>
         <message-counter-history-day-limit>10</message-counter-history-day-limit>

         <!-- Add these 2 lines -->
         <max-size-bytes>104857600</max-size-bytes>
         <address-full-policy>PAGE</address-full-policy>

      </address-setting>
   </address-settings>

Agora é possível ter enormes filas esperando para serem processadas.

Outras dicas

A partir de aqui Parece que sua pilha é muito pequena.

O colecionador paralelo jogará um excesso de memória se for gasto muito tempo na coleta de lixo: se mais de 98% do tempo total for gasto na coleta de lixo e menos de 2% do heap for recuperado, será lançado um excesso. Esse recurso foi projetado para impedir que os aplicativos funcionem por um longo período de tempo, enquanto fazem pouco ou nenhum progresso, porque a pilha é muito pequena. Se necessário, esse recurso pode ser desativado adicionando a opção -xx: -UsegCoverHeadLimit à linha de comando.

Você já tentou modificar suas opções de memória JVM e -Xmx (Memória máxima alocável) em particular? Suspeito que você precise aumentar sua memória JVM Max, para dar um espaço suficiente para processar suas mensagens.

Se estiver no desenvolvedor, você pode simplesmente soltar sua fila excluindo o diretório de trabalho do Hornetq (por exemplo,/Work/Hornetq).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top