HornetQ OutOfMemory en el arranque con gran revista

StackOverflow https://stackoverflow.com/questions/1941449

  •  20-09-2019
  •  | 
  •  

Pregunta

Uso: HornetQ 2.0.0.CR2 configuraciones por defecto para el servidor autónomo / no agrupado.

Cuando intento para que se inicie el servidor con una gran revista (> 1 Gb), tengo una excepción OutOfMemory: 

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

Esto podría suceder en la vida real cuando un consumidor deja de procesar los mensajes y yo tenga que reiniciar el servidor.

Hay alguna solución para esto? O las configuraciones que debería tratar de modificar?

¿Fue útil?

Solución

Resulta que era fácil de evitar por completo este problema.

La paginación no esta habilitado en la configuración por defecto!

La adición de estas 2 líneas en la hornetq-configuration.xml debe hacer el truco: 

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

Ahora es posible tener enormes colas de espera de ser procesados.

Otros consejos

aquí Parece que tu montón es demasiado pequeño.

  

El colector paralelo arrojará una   OutOfMemoryError si es demasiado tiempo   que se gasta en la recolección de basura: si   más de 98% del tiempo total es   empleado en la recolección de basura y menos   del 2% de la pila se recupera, una   OutOfMemoryError será lanzada. Esta   característica está diseñada para prevenir   la ejecución de aplicaciones para una   periodo prolongado de tiempo mientras que hace   poco o ningún progreso porque el montón   Es demasiado pequeño. Si es necesario, esta   función puede ser desactivada mediante la adición de la   opción -XX: -UseGCOverheadLimit a la   línea de comandos.

Ha intentado modificar sus opciones de memoria de JVM, y -Xmx (asignable máximo de memoria) en particular? Sospecho que necesita para aumentar la memoria del máximo JVM, para darle suficiente espacio para procesar los mensajes.

Si está activada, puede simplemente dejar caer la cola de un desarrollador eliminando el directorio de trabajo HornetQ (por ejemplo ~ / trabajo / hornetq).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top