Welche Anpassungen sollten vor dem Go Live an der Apache Active MQ Brokerkonfiguration vorgenommen werden? Gibt es hier Best Practices? Werden diese ausreichend in der Produktdokumentation beschrieben oder sind diese an anderer Stelle zu finden?
Einleitung
Apache Active MQ ist ein Opensource Messaging System, welches zur Auflösung der engen Kopplung zwischen Anwendungen genutzt werden kann. Neben der in diesem Projekt im Fokus stehenden Java JMS API wieder unter anderem auch eine REST, C und .NET API zur Kommunikation zwischen Anwendung und Messagingsystem zur Verfügung gestellt.
KahaDB Bug in der Active MQ Version 5.4.0
Damit Nachrichten dauerhaft gespeichert werden, muss ein persistenceAdapter konfiguriert werden. Hier ist aufgrund der Performancevorteile die KahaDB dem AMQ Message Store vorzuziehen. Wie Vorabtests der Apache Active MQ Instanz ergaben, besteht in der Apache Active MQ 5.4.0 Version ein Bug in der Implementierung der dateibasierten KahaDB. Die Nachrichten in Queues werden bei Nutzung in sogenannten Log-Dateien, unterhalb des kahadb Verzeichnis, abgebildet. Die Logdateien werden dabei schrittweise hochgezählt. Im Stresstest zeigte sich, dass Active MQ ab einem bestimmten Zeitpunkt, die Logdateien nicht mehr aufräumte. Selbst bei Leerung aller Queues blieben Log-Dateien bestehen. Parallel dazu wuchs der genutzte Java Heap kontinuierlich an. Mit einer Migration auf die Version 5.5.1 konnten beide Probleme behoben werden.
root@debian:/opt/apache-activemq-5.5.1/data/kahadb# ls
db-66.log db.data db.redo lock
Listing 1: Ablageort der KahaDB Logdateien
Optimierung für erhöhte Lastaufkommen
Bei erhöhter Last sollten im Startup Skript der Active MQ Instanz die Konfigurationsparameter zum Start der Instanz sowie das memoryUsage Limit hochgesetzt werden.
root@debian:/opt/apache-activemq-5.5.1/bin# cat activemq | grep Xmx
ACTIVEMQ_OPTS_MEMORY=”-Xms1024M -Xmx1024M”
Listing 2: Anpassung der Konfigurationsparameter am Beispiel des Default Startupskriptes
Anpassungen im Bereich Schwellwerte, Deadletter Queues, Logging & Security
In Abhängigkeit von der Anzahl der Clients, der Größe der Nachrichten und des Transaktionsumfanges sollten weiterhin die producerFlowControl memoryLimit Werte angepasst werden um das Blocking von Producern zu vermeiden. Einem Vollaufen der Festplatte kann mittels Setzen des storeUsage Wertes entgegengewirkt werden. Ein schwerwiegender Fehler tritt auf, wenn der storeUsage Wert nicht erreicht ist, aber die Festplatte bereits voll ist. Um eine automatische Reprozessierung von Nachrichten in Deadletter Queues zu ermöglichen, sollte grundsätzlich immer das Default DLQ Verhalten mittels einer deadLetterStrategy überschrieben werden. Das serverseitige Logging nach activemq.log erwies sich leider als weniger hilfreich. Häufig werden wichtige Fehler nur auf dem INFO Level geloggt. Dementsprechend sollte das Logging Level unbedingt hochgesetzt werden. Für clientseitiges Logging der Active MQ Bibliotheken ist unbedingt eine entsprechende log4j.properties zu hinterlegen. Ansonsten gibt der Java Client keinerlei Hinweise, die für das Debugging genutzt werden können. Im Security Bereich ist auf die Absicherung der Webkonsole und JMX-Schnittstelle sowie der Vergabe von Zugriffsrechten auf Queues und Topics zu achten.
<systemUsage>
<systemUsage sendFailIfNoSpace=”true”>
<memoryUsage>
<memoryUsage limit=”500 mb”/>
</memoryUsage>
<storeUsage>
<storeUsage limit=”1 gb”/>
</storeUsage>
<tempUsage>
<tempUsage limit=”100 mb”/>
</tempUsage>
</systemUsage>
</systemUsage>
Listing 3: Anpassung der Usage-Werte
Qualität der Produktdokumentation & alternative Informationsquellen
Insgesamt zeigte sich deutlich bei der Einführung von Apache Active MQ, dass individuelle Lasttests unter anderem zur Ermittlung geeigneter Schwellwerte für Limit-Werte absolut unverzichtbar sind. Hier gibt es keine allgemeinen Berechnungsformeln. Viele der offenen Fragen konnten lediglich durch den Austausch mit aktiven Active MQ Comittern beantwortet werden. Sehr enttäuscht war ich von der Active MQ Produktdokumentation, die bestimmte Konfigurationsparameter häufig kaum oder in einem Fall sogar fehlerhaft beschreibt. Hier erwies sich das Active MQ Forum als deutlich bessere erste Anlaufstelle.
