HornetQ OutOfMemory au démarrage avec grand journal

Question

Utilisation: HornetQ 2.0.0.CR2 Les configurations par défaut pour la version autonome / non-cluster serveur.

Lorsque je tente de démarrer le serveur avec un grand journal (> 1Go), je suis une exception 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)

Cela pourrait se produire dans la vie réelle quand un traitement arrête les messages consommateurs et je dois redémarrer le serveur.

Il existe une solution de contournement pour cela? Ou quelles configurations dois-je essayer de modifier?

Answer 1

Il se trouve qu'il était simple d'éviter complètement ce problème.

Paging il est pas activé dans la configuration par défaut!

L'ajout de ces 2 lignes sur le hornetq-configuration.xml devrait faire l'affaire:

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

Maintenant, il est possible d'avoir d'énormes files d'attente à traiter.

Answer 2

De ici il semble que votre tas est trop petit.

  

Le collecteur parallèle lancera une   OutOfMemoryError si trop de temps   dépensé dans la collecte des déchets: si   plus de 98% de la durée totale est   passé dans la collecte des ordures et moins   On récupère que 2% de la masse, un   OutOfMemoryError sera jeté. Cette   fonctionnalité est conçue pour empêcher   les applications en cours d'exécution à partir d'un   période de temps prolongée tout en   peu ou pas de progrès parce que le tas   c'est trop petit. Si nécessaire, cette   fonctionnalité peut être désactivée en ajoutant le   l'option -XX: -UseGCOverheadLimit à la   ligne de commande.

Avez-vous essayé de modifier vos options de mémoire JVM et -Xmx (allocatable mémoire max) en particulier? Je suppose que vous devez augmenter votre JVM mémoire max, pour lui donner suffisamment de marge pour traiter vos messages.

Answer 3

Si elle est un développeur, vous pouvez simplement laisser tomber votre file d'attente en supprimant votre HornetQ répertoire de travail (par exemple ~ / travail / hornetq).