In der Vergangenheit habe ich mich ja bereits öfters mit dem Clustering des JBoss Application Servers beschäftigt, doch das JMS-Clustering mit Anpassung der entsprechenden JEE-Services war eine Premiere. Ausgangspunkt war, dass wir mehrere JEE-Services auf MDB-Basis hatten, die die interne HSQL-DB genutzt haben. Diese Services sollten ausfallsicher laufen. Aus diesem Grund haben wir uns für ein “echtes” Clustering der Message-Queues mit einer zentralen Datenbank-Instanz entschieden.
Vor ein paar Tagen hatte ich ein interessantes Problem: bei JBoss 4 war es sehr einfach, Queues für MDBs zu erzeugen. Einfach destination und destinationType in die @ActivationConfigProperty eintragen und beim Deployment werden werden die Queues automatisch erzeugt. Leider ist das bei JBoss 5 nicht mehr ganz so einfach. Der Trick ist, in der jboss.xml das Tagtruehinzuzufügen und auf die entsprechende EJB und die anzulegende Queue zu verweisen (die jboss.xml liegt im META-INF-Verzeichnis). Im Ganzen sieht das folgendermaßen aus:
<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
version="3.0">
<enterprise-beans>
<message-driven>
<ejb-name>QueueCreateMDB</ejb-name>
<destination-jndi-name>queue/myQueue</destination-jndi-name>
<create-destination>true</create-destination>
</message-driven>
</enterprise-beans>
</jboss>
Die dazu passende MessageBrivenBean sieht so aus:
@MessageDriven(name="QueueCreateMDB", activationConfig={
@javax.ejb.ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
@javax.ejb.ActivationConfigProperty(propertyName="destination", propertyValue="queue/myQueue"),
@javax.ejb.ActivationConfigProperty(propertyName="useDLQ", propertyValue="false"),
@javax.ejb.ActivationConfigProperty(propertyName="acknowledgeMode", propertyValue="Auto-acknowledge")},
messageListenerInterface=MessageListener.class)
public class QueueCreateMDB implements MessageListener {
Dadurch wird beim Deployment die angegebene Queue angelegt.
Ich sollte Beta-Tester bei RedHat werden: ich habe drei Cases im Support-Portal aufgemacht und es sind zwei Bugs aufgemacht worden. Dieses Mal habe ich einen OutOfMemory-Alert aufgesetzt: Ziel war es, dass ein Alert ausgelöst wird, wenn ein java.lang.OutOfMemory-Error im server.log-file des JBoss auftaucht. Dazu habe ich einen Alert und einen entsprechenden Recovery Alert definiert. Problem war: der Recovery Alert hat nicht gezogen. Das Problem war, dass ich die Availability des Recovery Alerts auf “Comes up” gesetzt habe, was offensichtlich nicht funktioniert. Ein Workaround ist, dass ein zusätzlicher Event auf den Start des App-Servers gelegt wird (“Started in:”), was aber sehr unschön ist, da der JON dann mit Events zugespamt wird. Wie dem auch sei: hier ist der Bug zu finden.
Update: Hach, geht auch nicht … so muss es sein: bei “Condition” muss “Operation Execution [restart] with result status [SUCCESS]” eingestellt werden, dann geht es. Darüber hinaus hatte ich das Problem, dass der Restart immer Timeouts bekommen hat, nach dem Ändern der Log4j-Konfiguration (!!!) hat es dann funktioniert. Sehr sonderbar, zumal der Restart als Skript implementiert ist und explizit nicht über JMX. Irgendwie macht mir das ernsthaft Bauchschmerzen …
Diese Woche habe ich ein wenig mit JON 3 rumgespielt und wollte natürlich auch ein kleines Plugin schreiben. Also habe ich mir eine working copy des Git-Repositories von RHQ ausgecheckt und versucht, die “samples” mit “mvn install” zu bauen. Leider musste ich feststellen, dass das nicht funktioniert:
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.custom:simplereport-serverplugin:jar:1.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 91, column 18
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building RHQ Simple Report Server Plugin 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ simplereport-serverplugin ---
[INFO] Deleting C:\data\git\rhq\simplereport-serverplugin\target
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ simplereport-serverplugin ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ simplereport-serverplugin ---
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent!
[INFO] Compiling 1 source file to C:\data\git\rhq\simplereport-serverplugin\target\classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
Meine erste Annahme war, dass ich irgendwo einen Fehler gemacht habe, die pom-Files sahen aber in Ordnung aus, also habe ich mich an den RedHat-Support gewandt. Ergebnis: das ist leider ein Bug, der immer auftritt, wenn kein RHQ-Maven-Repository vorhanden ist bzw. wenn dieses leer ist. Sehr unschön.
