HornetQ OutOfMemory beim Start mit großer Zeitschrift

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

  •  20-09-2019
  •  | 
  •  

Frage

Mit: HornetQ 2.0.0.CR2 Standardkonfigurationen für den Stand-alone / Nicht-Cluster-Server.

Wenn ich versuche, den Server mit einer großen Zeitschrift zum Start (> 1 GB), bekam ich eine OutOfMemory Ausnahme: 

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

Das im wirklichen Leben passieren könnte, wenn ein Verbraucher die Verarbeitung von Nachrichten stoppt, und ich brauche den Server neu zu starten.

Es gibt jede Abhilfe für dieses? Oder welche Konfigurationen soll ich versuchen, zu ändern?

War es hilfreich?

Lösung

Es stellt sich heraus, es war einfach zu vollständig dieses Problem zu vermeiden.

Die Paging es ist nicht in der Standardkonfiguration aktiviert!

Das Hinzufügen dieser zwei Linien auf der HornetQ-configuration.xml sollte es tun: 

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

Jetzt ist es möglich, riesige Warteschlangen zu haben, warten verarbeitet werden.

Andere Tipps

hier es erscheint Ihre Heap ist zu klein.

  

Der parallele Kollektor wird ein Wurf   OutOfMemoryError wenn zu viel Zeit ist   wobei in Garbage Collection ausgegeben: if   mehr als 98% der Gesamtzeit ist   in Garbage Collection verbracht und weniger   als 2% des Haufens zurückgewonnen wird, ein   OutOfMemoryError wird geworfen werden. Diese   Funktion wurde entwickelt, um zu verhindern   Anwendungen vom Laufen für eine   längere Zeit während machen   wenig oder gar keine Fortschritte, weil die Halde   es ist zu klein. Falls erforderlich, diese   Funktion kann durch Hinzufügen der deaktiviert werden   Option -XX: -UseGCOverheadLimit auf die   Befehlszeile.

Haben Sie Ihre JVM-Speicheroptionen versucht, Ändern und -Xmx (max Speicher zuweisbaren) Bestimmtes? Ich vermute, Sie benötigen, um Ihre JVM Max-Speicher zu erhöhen, ist es genügend Spielraum zu geben, um Ihre Nachrichten zu verarbeiten.

Wenn es auf einem Entwickler ist man einfach die Warteschlange fallen kann Ihr HornetQ Arbeitsverzeichnis durch Löschen (z ~ / work / HornetQ).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top