Neuheiten in Version 4.0

Message Queue 4.0 umfasst die folgenden neuen Funktionen:

• Schnittstellenänderungen an der C-API und der C-Clientlaufzeit

• Schnittstellenänderungen an der Java-API und der Java-Clientlaufzeit

• Anzeigen von Informationen zum persistenten Speicher

• Formatänderungen für die persistente Speicherung

• Broker-Verwaltung

• JDBC-Persistenzunterstützung

• SSL-Unterstützung

• JMX-Unterstützung

• Protokollierung zur Client-Laufzeit

• Verbindungsereignisbenachrichtigung

Die genannten Themen werden in den folgenden Unterabschnitten näher beschrieben.

Eine der eher kleinen, jedoch wichtigen Änderungen, die mit Version 4.0 eingeführt wurden, ist die Tatsache, dass die Befehlszeilenoption nun nicht mehr zur Angabe eines Passworts verwendet werden kann. Daher müssen nun alle Passwörter in einer Datei gespeichert werden, wie unter Veraltete Passwortoption beschrieben.

Schnittstellenänderungen an der C-API und der C-Clientlaufzeit

Version 4.0 von Message Queue fügt zwei Eigenschaften hinzu, die für alle Nachrichten gesetzt werden, die in einer Warteschlange mit nicht zugestellten Nachrichten platziert wurden.

• JMS_SUN_DMQ_PRODUCING_BROKER zeigt dem Broker an, wo die Nachricht generiert wurde.

• JMS_SUN_DMQ_DEAD_BROKER zeigt dem Broker an, wer die Nachricht als nicht zugestellt gekennzeichnet hat.

Schnittstellenänderungen an der Java-API und der Java-Clientlaufzeit

Version 4.0 von Message Queue fügt zwei Eigenschaften hinzu, die für alle Nachrichten gesetzt werden, die in einer Warteschlange mit nicht zugestellten Nachrichten platziert wurden.

• JMS_SUN_DMQ_PRODUCING_BROKER zeigt dem Broker an, wo die Nachricht generiert wurde.

• JMS_SUN_DMQ_DEAD_BROKER zeigt dem Broker an, wer die Nachricht als nicht zugestellt gekennzeichnet hat.

Anzeigen von Informationen zum persistenten Speicher

Der Unterbefehl query wurde zum Befehl imqdbmgr hinzugefügt. Verwenden Sie diesen Unterbefehl zum Anzeigen von Informationen zum persistenten Speicher (u. a. Speicherversion, Datenbankbenutzer und ob die Datenbanktabellen erstellt wurden).

Im Folgenden finden Sie ein Beispiel für die Informationen, die über diesen Befehl angezeigt werden.

imqdbmgr query

[04/Oct/2005:15:30:20 PDT] Verwenden des integrierten Persistenzspeichers:
        Version=400
        Broker-ID=Mozart1756
        Datenbankverbindung url=jdbc:oracle:thin:@Xhome:1521:mqdb
        Datenbankbenutzer=scott
Ausführen im Standalone-Modus.
Datenbanktabellen wurden bereits erstellt.

Formatänderungen für die persistente Speicherung

In Version 3.7 UR1 von Message Queue wurden zur Verbesserung der Leistung zwei Änderungen am persistenten Speicherformat eingeführt. Eine Änderung betrifft den Dateispeicher, die andere den JDBC-Speicher.

• Format von Transaktionsdaten im Dateispeicher beibehalten

  Das Format von Transaktionsstatusinformationen, die im dateibasierten persistenten Speicher von Message Queue gespeichert werden, wurde geändert, um die Datenträger-E/A-Vorgänge zu reduzieren und die Leistung von JMS-Transaktionen zu verbessern.

• Oracle JDBC-Speicher

  In vorherigen Versionen von Message Queue hat das Speicherschema für Oracle den Datentyp LONG RAW zum Speichern von Nachrichtendaten verwendet. Mit Oracle 8 wurde der Datentyp BLOB eingeführt, der den Typ LONG RAW ablöste. In Message Queue 3.7 UR1 wurde zum Datentyp BLOB gewechselt, um die Leistung zu verbessern und bessere Unterstützungsmöglichkeiten zu bieten.

Da sich diese Änderungen auf die Speicherkompatibilität auswirken, wurde die Speicherversion für Dateispeicher und JDBC-Speicher in Version 3.7 UR1 von Message Queue von 350 in 370 geändert.

In Version 4.0 von Message Queue wurden Änderungen am JDBC-Speicher eingeführt, um die Leistung zu optimieren und zukünftige Erweiterungen zu unterstützen. Aus diesem Grund wurde die Version des JDBC-Speichers in 400 geändert. Beachten Sie, dass in Version 4.0 die Version des dateibasierten persistenten Speichers weiterhin 370 lautet, da hier keine Änderungen durchgeführt wurden.

Message Queue 4.0 unterstützt die automatische Konvertierung des persistenten Speichers in die neuesten Versionen der dateibasierten persistenten Speicher sowie der persistenten JDBC-Speicher. Beim erstmaligen Ausführen von imqbrokerd wird ein älterer Speicher (sofern vorhanden) in das neue Format migriert.

• Die Versionen 200 und 350 des dateibasierten Speichers werden in das Format der Version 370 migriert.

• Die Versionen 350 und 370 des JDBC-Speichers werden in das Format der Version 400 migriert. (Wenn Sie einen Speicher der Version 200 aktualisieren müssen, muss zunächst die Version 3.5 oder 3. 6 als Zwischenversion verwendet werden.)

Wenn Sie für dieses Upgrade ein Rollback durchführen müssen, können Sie Message Queue 4.0 deinstallieren und anschließend erneut die Version installieren, die zuvor ausgeführt wurde. Da die ältere Kopie des Speichers beibehalten wird, kann der Broker mit der älteren Kopie des Speichers ausgeführt werden.

Broker-Verwaltung

Im Dienstprogramm Command (imqcmd) sind ein neuer Unterbefehl und verschiedene neue Optionen verfügbar, über welche Administratoren den Broker inaktivieren, den Broker nach einem festgelegten Intervall herunterfahren, eine Verbindung löschen oder Java-Systemeigenschaften hinzufügen können (z. B. verbindungsbezogene Eigenschaften).

• Bei der Inaktivierung des Brokers wird dieser in einen inaktiven Zustand versetzt, in dem Nachrichten entfernt werden können, bevor der Broker heruntergefahren oder neu gestartet wird. Zu einem Broker, der inaktiviert wird, können keine neuen Verbindungen erstellt werden. Um den Broker zu inaktivieren, geben Sie einen Befehl ähnlich dem folgenden ein.

  imqcmd quiesce bkr -b Wolfgang:1756

• Um den Broker nach einem bestimmten Intervall herunterzufahren, geben Sie einen Befehl ähnlich dem folgenden ein. (Das Zeitintervall gibt die Anzahl an Sekunden bis zum Herunterfahren des Brokers an.)

  imqcmd shutdown bkr -b Hastings:1066 -time 90

  Wenn Sie ein Zeitintervall angeben, protokolliert der Broker eine Meldung, die darauf hinweist, wann er heruntergefahren wird. Beispiel:

  Broker wird in 29 Sekunden (29996 Millisekunden) heruntergefahren.

  Während der Broker auf das Herunterfahren wartet, wird sein Verhalten folgendermaßen beeinflusst.

  • Administrative JMS-Verbindungen werden weiterhin akzeptiert.

  • Neue JMS-Verbindungen werden nicht akzeptiert.

  • Bestehende JMS-Verbindungen werden weiterhin funktionieren.

  • Der Broker kann nicht die Funktionen für einen anderen Broker in einem Hochverfügbarkeits-Cluster übernehmen.

  • Das Dienstprogramm imqcmd wird nicht gesperrt, es wird die Anforderung zum Herunterfahren des Brokers senden und umgehend zurückgeben.

• Um eine Verbindung zu löschen, geben Sie einen Befehl ähnlich dem folgenden ein.

  imqcmd destroy cxn -n 2691475382197166336

  Verwenden Sie den Befehl imqcmd list cxn oder imqcmd query cxn, um die Verbindungs-ID abzurufen.

• Zur Angabe einer Systemeigenschaft über den Befehl imqcmd verwenden Sie die neue –D-Option. Dies ist nützlich, um die Werkseinstellungen der JMS-Verbindung oder verbindungsbezogene Java-Systemeigenschaften außer Kraft zu setzen. Beispiel:

  imqcmd list svc -secure -DimqSSLIsHostTrusted=true
  imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore 
              -Djavax.net.ssl.trustStorePassword=mytrustword

Vollständige Informationen zur Syntax des Befehls imqcmd finden Sie in Kapitel 13, Command Line Reference in Sun Java System Message Queue 4.1 Administration Guide.

JDBC-Persistenzunterstützung

Apache Derby Version 10.1.1 wird jetzt als JDBC-kompatibler Persistenzspeicheranbieter unterstützt.

SSL-Unterstützung

Ab Version 4.0 ist der Standardwert für die Werkseinstellung der Clientverbindung imqSSLIsHostTrusted auf false gesetzt. Wenn die Anwendung jedoch von dem vorherigen Standardwert true abhängt, müssen Sie die Eigenschaft neu konfigurieren und ausdrücklich auf true setzen.

Möglicherweise vertrauen Sie dem Host, wenn der Broker so konfiguriert ist, dass er selbst signierte Zertifikate verwendet. In diesem Fall sollten Sie zusätzlich zur Angabe, dass die Verbindung einen SSL-basierten Verbindungsdienst verwenden soll (über die imqConnectionType-Eigenschaft), die Eigenschaft imqSSLIsHostTrusted auf "true" setzen.

Um Clientanwendungen sicher auszuführen, wenn der Broker selbst signierte Zertifikate verwendet, verwenden Sie beispielsweise einen ähnlichen Befehl wie den folgenden.

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true <Clientanwendungsname>

Um das Verwaltungstool imqcmd sicher auszuführen, wenn der Broker selbst signierte Zertifikate verwendet, verwenden Sie einen ähnlichen Befehl wie den folgenden.

imqcmd list svc -secure -DimqSSLIsHostTrusted=true

JMX-Unterstützung

Für die Konfiguration und Überwachung von Message Queue-Brokern wurde in Übereinstimmung mit der JMX-Spezifikation (Java Management Extensions) eine neue API hinzugefügt. Mithilfe dieser API haben Sie die Möglichkeit, Broker-Funktionen programmatisch in einer Message Queue-Clientanwendung zu konfigurieren und zu überwachen. In früheren Versionen von Message Queue war der Zugriff auf diese Funktionen ausschließlich über die Befehlszeile oder die Administrationskonsole möglich.

Die API besteht aus mehreren JMX-MBeans (Managed Beans) zur Verwaltung der folgenden mit Message Queue verbundenen Ressourcen:

• Nachrichten-Broker

• Verbindungsdienste

• Verbindungen

• Ziele

• Nachrichtenproduzenten

• Nachrichtenkonsumenten

• Transaktionen

• Broker-Cluster

• Protokollierung

• Die JVM (Java Virtual Machine)

Diese MBeans stellen Attribute und Operationen für das synchrone Abrufen und Manipulieren des Status der zugrunde liegenden Ressourcen bereit, sowie Benachrichtigungen, über die eine Clientanwendung Statusänderungen überwachen und asynchron darauf antworten kann, sobald diese auftreten. Mithilfe der JMX-API können Clientanwendungen Konfigurations- und Überwachungsaufgaben wie die folgenden durchführen:

• Festlegen von Portnummern für Broker

• Festlegen der maximalen Nachrichtengröße für Broker

• Anhalten eines Verbindungsdienstes

• Festlegen der maximalen Anzahl an Threads für einen Verbindungsdienst

• Abrufen der aktuellen Anzahl der Verbindungen mit einem Dienst

• Löschen einer Verbindung

• Erstellen eines Zieles

• Löschen eines Zieles

• Aktivieren oder deaktivieren der automatischen Erstellung von Zielen

• Bereinigen aller Nachrichten in einem Ziel

• Abrufen der Gesamtzahl an Nachrichten, die von einem Ziel seit dem Broker-Start empfangen wurden

• Abrufen des aktuellen Status (ausgeführt oder angehalten) einer Warteschlange

• Abrufen der aktuellen Anzahl an Nachrichtenproduzenten für ein Thema

• Bereinigen aller Nachrichten eines dauerhaften Abonnenten

• Abrufen der aktuellen JVM-Heap-Größe

Eine Einführung in die JMX-API und vollständige Referenzinformationen finden Sie im Sun Java System Message Queue 4.1 Developer’s Guide for JMX Clients .

Broker-Unterstützung: JMX-bezogene Eigenschaften

Zur Unterstützung der JMX-API wurden mehrere neue Broker-Eigenschaften hinzugefügt(siehe Tabelle 1–3). Keine dieser Eigenschaften kann über die Befehlszeile mit dem Message Queue-Dienstprogramm Command (imqcmd) festgelegt werden. Stattdessen besteht die Möglichkeit, diese über die -D-Option des Broker-Dienstprogramms (imqbrokerd) festzulegen oder sie manuell in der Instanzkonfigurationsdatei des Brokers ( config.properties) zu bearbeiten. Zudem lassen sich einige dieser Eigenschaften (imq.jmx.rmiregistry.start, imq.jmx.rmiregistry.use, imq.jmx.rmiregistry.port) mit den neuen Broker-Dienstprogrammoptionen festlegen, die in Tabelle 1–4 beschrieben werden. In der Tabelle sind sämtliche Optionen mit Angaben zu Typ und Verwendung enthalten.

   /jndi/rmi://Broker-Host:RMI-Port
      /Broker-Host/Broker-Port/Connector-Name

   /stub/RMI-Stub

Die Eigenschaft imq.jmx.connector.list definiert eine Reihe benannter JMX-Connectors, die beim Broker-Start erstellt werden; imq.jmx.connector.activelist legt fest, welcher dieser Connectors aktiviert werden soll. Jeder benannte Connector verfügt somit über eigene Eigenschaften:

Standardmäßig werden zwei JMX-Connectors namens jmxrmi und ssljmxrmi erstellt. Entsprechend der Konfiguration verwendet der erste keine SSL-Verschlüsselung (imq.jmx.connector.jmxrmi.useSSL = false und der zweite verwendet diese (imq.jmx.connector.ssljmxrmi.useSSL = true). Per Voreinstellung ist nur der jmxrmi-Connector beim Broker-Start aktiviert. Weitere Informationen zum Aktivieren des ssljmxrmi-Connector für eine sichere Kommunikation finden Sie unter SSL-Unterstützung für JMX-Clients.

Zudem wurden neue Optionen (Tabelle 1–4) zum Befehlszeilendienstprogramm Broker hinzugefügt (imqbrokerd), um die Nutzung, den Startvorgang und den Port für die RMI-Registrierung zu steuern. Die Verwendungs- und Wirkungsweise dieser Optionen entspricht der der äquivalenten Broker-Eigenschaften, die in Tabelle 1–3 beschrieben sind. In der Tabelle sind alle Optionen mit der jeweiligen äquivalenten Broker-Eigenschaft und Beschreibung aufgeführt.

Ein neuer Unterbefehl (Tabelle 1–5) wurde zum Befehlszeilendienstprogramm Command (imqcmd) für die Auflistung der JMX-Dienst-URLs von JMX-Connectors hinzugefügt, die beim Broker-Start erstellt und gestartet wurden. Diese Information wird von JMX-Clients benötigt, die nicht die Message Queue-Convenience-Klasse AdminConnectionFactory verwenden, um die JMX-Connectors abzurufen. Darüber hinaus kann sie zum Verwalten und Überwachen von Message Queue über einen generischen JMX-Browser, wie Java Monitoring und Management Console ( jconsole), verwendet werden.

SSL-Unterstützung für JMX-Clients

Wie oben bereits erwähnt, ist der Message Queue-Nachrichten-Broker standardmäßig für eine sichere Kommunikation über den vordefinierten JMX-Connector jmxrmi konfiguriert. Für Anwendungen muss zur Verwendung von SSL (Secure Socket Layer) für eine sichere Kommunikation der alternative, sichere JMX-Connector ssljmxrmi aktiviert werden. Dies erfordert die folgenden Schritte:

1. Rufen Sie ein signiertes Zertifikat ab, und installieren Sie dieses so, wie es für die Verbindungsdienste ssljms, ssladmin oder cluster im Message Queue Administration Guide beschrieben wird.

2. Installieren Sie das Root-Zertifizierungsstellenzertifikat im Vertrauensspeicher, falls erforderlich.

3. Fügen Sie den ssljmxrmi-Connector zur Liste der JMX-Connectors hinzu, damit dieser beim Broker-Start aktiviert wird:

   imq.jmx.connector.activelist=jmxrmi,ssljmxrmi

4. Starten Sie den Broker mit dem Message Queue-Dienstprogramm Broker (imqbrokerd), indem Sie diesem entweder das Schlüsselspeicher-Passwort in einer Passwortdatei übergeben oder es bei Aufforderung in die Befehlszeile eingeben.

5. Standardmäßig ist der ssljmxrmi-Connector (oder jeder andere SSL-basierte Connector) konfiguriert, um sämtliche bereitgestellten Broker-SSL-Zertifikate zu validieren. Um diese Validierung zu verhindern (wenn Sie z. B. selbst signierte Zertifikate beim Testen von Software verwenden), setzen Sie die Broker-Eigenschaft imq.jmx.connector.ssljmxrmi.brokerHostTrusted auf true.

Auf Clientseite muss das Administrator-Verbindungsfactory (AdminConnectionFactory) mit einer URL konfiguriert sein, die ssljmxrmi als bevorzugten Connector angibt:

AdminConnectionFactory  acf = new AdminConnectionFactory();
acf.setProperty(AdminConnectionConfiguration.imqAddress, "mq://myhost:7676/ssljmxrmi");

Verwenden Sie erforderlichenfalls die Systemeigenschaften javax.net.ssl.trustStore und javax.net.ssl.trustStorePassword, um den JMX-Client mit dem Vertrauensspeicher zu verknüpfen.

Protokollierung zur Client-Laufzeit

In diesem Abschnitt wird die Message Queue 4.0-Unterstützung für die Protokollierung von verbindungs- und sitzungsbezogenen Ereignissen zur Client-Laufzeit beschrieben.

JDK 1.4 (und höher) enthält die java.util.logging-Bibliothek. Diese Bibliothek implementiert eine standardmäßige Protokollschnittstelle, die zur anwendungsspezifischen Protokollierung verwendet werden kann.

Die Message Queue-Client-Laufzeit nutzt die Java-Protokoll-API, um deren Protokollierungsfunktionen zu implementieren. Sie können sämtliche J2SE 1.4-Protokolloptionen zum Konfigurieren der Protokollierungsaktivitäten verwenden. Beispielsweise können von einer Anwendung die folgenden Java-Protokolloptionen verwendet werden, um festzulegen, wie die Protokollinformationen von der Message Queue-Client-Laufzeit ausgegeben werden:

• Protokoll-Handler

• Protokollfilter

• Protokollformatierungen

• Protokollebene

Weitere Informationen zur Java-Protokoll-API finden Sie in der Übersicht über die Java-Protokollierung unter http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html

Protokollnamensräume, -ebenen und -aktivitäten

Der Message Queue-Anbieter definiert mehrere Protokollnamensräume, die mit Protokollebenen und Protokollaktivitäten verknüpft sind, über die Message Queue-Clients Verbindungs- und Sitzungsereignisse protokollieren können, sofern die Protkollkonfiguration entsprechend festgelegt wurde.

Der Root-Protokollnamensraum für die Message Queue-Client-Laufzeit ist als javax.jms definiert. Für alle Protokolle in der Message Queue-Client-Laufzeit wird dieser Name als übergeordneter Namensraum verwendet.

Die für die Message Queue-Client-Laufzeit verwendeten Protokollebenen stimmen mit denen überein, die in der java.util.logging.Level-Klasse definiert sind. Diese Klasse definiert sieben Standardprotokollebenen und zwei zusätzliche Einstellungen, über die Sie die Protokollierung aktivieren bzw. deaktivieren können.

OFF

Deaktiviert die Protokollierung.

SEVERE

Höchste Priorität, höchster Wert. Anwendungsdefiniert.

WARNING

Anwendungsdefiniert.

INFO

Anwendungsdefiniert.

CONFIG

Anwendungsdefiniert.

FINE

Anwendungsdefiniert.

FINER

Anwendungsdefiniert.

FINEST

Niedrigste Priorität, niedrigster Wert. Anwendungsdefiniert.

ALL

Aktiviert die Protokollierung aller Nachrichten.

Im Allgemeinen werden Ausnahmen und Fehler, die zur Message Queue-Client-Laufzeit auftreten, im Protokoll mit dem javax.jms-Namensraum erfasst.

• Ausnahmefehler, die von der JVM ausgelöst und von der Client-Laufzeit abgefangen werden, z. B. IOException, werden bei der Protokollierung mit dem Protokollnamensraum javax.jms auf der Ebene WARNING erfasst.

• JMS-Ausnahmen, die von der Client-Laufzeit ausgelöst werden, z. B. IllegalStateException , werden bei der Protokollierung mit dem Protokollnamensraum javax.jms auf der Ebene FINER erfasst.

• Fehler, die von der JVM zurückgegeben und von der Client-Laufzeit abgefangen werden, z. B. OutOfMemoryError, werden bei der Protokollierung mit dem Protokollnamensraum javax.jms auf der Ebene SEVERE erfasst.

In den folgenden Tabellen sind die Ereignisse aufgelistet, die protokolliert werden können, sowie die Protokollebene, die festgelegt werden muss, um Ereignisse für JMS-Verbindungen und für Sitzungen zu protokollieren.

Die folgende Tabelle enthält Beschreibungen der Protokollebenen und Ereignisse für Verbindungen.

Für Sitzungen werden die folgenden Informationen im Protokolleintrag erfasst.

• Jeder Protokolleintrag für eine an den Konsumenten übermittelte Nachricht umfasst ConnectionID, SessionID und ConsumerID.

• Jeder Protokolleintrag für eine Nachricht, die von einem Produzenten gesendet wurde, umfasst ConnectionID, SessionID, ProducerID und Zielname.

Die folgende Tabelle enthält Beschreibungen der Protokollebenen und Ereignisse für Sitzungen.

Die Ausgabeprotokollebene wird standardmäßig aus der JRE übernommen, in der die Anwendung ausgeführt wird. Überprüfen Sie die Datei JRE_DIRECTORY/lib/logging.properties , um diese Ebene zu bestimmen.

Sie haben die Möglichkeit, die Protokollierung programmatisch oder mithilfe von Konfigurationsdateien zu konfigurieren. Zudem können Sie den Umfang der Protokollierung steuern. In den folgenden Abschnitten werden diese Möglichkeiten erläutert.

Verwenden der Konfigurationsdatei für das JRE-Protokoll

Das folgende Beispiel zeigt, wie Protokollnamensräume und -ebenen in der Datei JRE_DIRECTORY/lib/logging.properties angegeben werden, die verwendet wird, um die Protokollebene für die Java Runtime Environment festzulegen. Sämtliche Anwendungen, die diese JRE verwenden, verfügen über dieselbe Protokollkonfiguration. In der nachstehenden Beispielkonfiguration wird die Protokollebene für den javax.jms.connection -Namensraum auf INFO gesetzt, und angegeben, dass die Ausgabe in java.util.logging.ConsoleHandler geschrieben werden soll.

#logging.properties file.
# "Handler" geben eine durch Kommas getrennte Liste der Protokoll-Handler-Klassen 
# an. Diese Handler werden während des VM-Starts installiert.
# Beachten Sie, dass sich diese Klassen im selben Systemklassenpfad befinden müssen.
# Standardmäßig wird nur ein ConsoleHandler konfiguriert, der
# nur Meldungen auf INFO-Ebene und höheren Ebenen anzeigt.

	handlers= java.util.logging.ConsoleHandler

# Standardmäßige globale Protokollebene.
# Dies gibt an, welche Ereignisse in allen Protokollen
# erfasst werden. Für jede vorgegebene Funktion kann diese allgemene Ebene
# von einer funktionsspezifischen Ebene überschrieben werden.
# Beachten Sie, dass der ConsoleHandler ebenfalls über eine separate Ebeneneinstellung verfügt,
# über die in der Konsole gedruckten Meldungen eingeschänkt werden können.

    .level= INFO

# Grenzen Sie die Meldungen ein, die auf der Konsole für INFO und höher gedruckt werden.

    java.util.logging.ConsoleHandler.level = INFO
    java.util.logging.ConsoleHandler.formatter = 
                                    java.util.logging.SimpleFormatter

# Bei der Protokollierung mit javax.jms.connection-Namensraum
# werden Level.INFO-Nachrichten für die entsprechenden Ausgabe-Handler geschrieben.
# In dieser Konfiguration ist der Ausgabe-Handler auf java.util.logging.ConsoleHandler gesetzt.

    javax.jms.connection.level = INFO

Verwenden einer Protokollierungskonfigurationsdatei für eine bestimmte Anwendung

Sie können zudem eine Protokollierungskonfigurationsdatei über die Java-Befehlszeile definieren, die Sie verwenden, um eine Anwendung auszuführen. Die Anwendung wird dann die Konfiguration in der angegebenen Protokolldatei verwenden. Im folgenden Beispiel verwendet configFile dasselbe Format, das in der Datei JRE_DIRECTORY/lib/logging.properties definiert ist.

java -Djava.util.logging.config.file=configFile MQApplication

Programmatisches Festlegen der Protokollkonfiguration

Im folgenden Code wird die java.util.logging-API zum Protokollieren von Verbindungsereignissen verwendet, indem die Protokollebene für den javax.jms.connection-Namensraum auf FINE geändert wird. Sie können einen solchen Code in die Anwendung einfügen, um die Protokollkonfiguration programmatisch festzulegen.

import java.util.logging.*;
//einen Datei-Handler erzeugen und in der mq.log-Datei 
//im Temp-Verzeichnis des Systems ausgeben.

    Handler fh = new FileHandler("%t/mq.log");
    fh.setLevel (Level.FINE);

//Protokoll für Domäne "javax.jms.connection" abrufen.

    Logger logger = Logger.getLogger("javax.jms.connection");
    logger.addHandler (fh);

//javax.jms.connection-Protokollierung würde Aktivitäten 
//der Ebene FINE und höher erfassen.

    logger.setLevel (Level.FINE);

Verbindungsereignisbenachrichtigung

Verbindungsereignisbenachrichtigungen ermöglichen einem Message Queue-Client das Schließen und erneute Verbinden von Ereignissen zu überwachen und dem Benachrichtigungstyp und Verbindungsstatus entsprechende Aktionen auszuführen. Wenn es beispielsweise zu einem Failover kommt und der Client mit einem anderen Broker erneut verbunden wird, wird in einer Anwendung möglicherweise der Transaktionsstatus bereinigt, um mit einer neuen Transaktion fortzufahren.

Wenn der Message Queue-Anbieter ein schwerwiegendes Problem mit einer Verbindung ermittelt, ruft dieser den registrierten Ausnahme-Listener des Verbindungsobjekts auf. Er ruft die onException-Methode des Listeners auf, und übergibt dieser ein JMSException-Argument, welches das Problem beschreibt. Der Message Queue-Anbieter bietet zudem eine Ereignisbenachrichtigungs-API, die es der Client-Laufzeit ermöglicht, die Anwendung über Änderungen des Verbindungsstatus zu informieren. Die Benachrichtigungs-API wird durch die folgenden Elemente definiert:

• Das com.sun.messaging.jms.notification-Paket, das den Ereignis-Listener und die Benachrichtigungsereignisobjekte definiert.

• Die com.sun.messaging.jms.Connection-Schnittstelle, die die Erweiterungen der javax.jms.Connection-Schnittstelle definiert.

In den folgenden Abschnitten werden die Ereignisse beschrieben, die Benachrichtigungen auslösen können, und wie ein Ereignis-Listener erstellt wird.

Verbindungsereignisse

In der folgenden Tabelle sind die Ereignisse aufgelistet und beschrieben, die vom Ereignis-Listener zurückgegeben werden können.

Beachten Sie, dass der JMS-Ausnahme-Listener nicht aufgerufen wird, wenn ein Verbindungsereignis ausgelöst wird. Der Ausnahme-Listener wird nur dann aufgerufen, wenn die Client-Laufzeit die maximale Anzahl an Versuchen zum Wiederherstellen der Verbindung erreicht hat. Die Client-Laufzeit ruft den Ereignis-Listener immer vor dem Ausnahme-Listener auf.

Erstellen eines Ereignis-Listeners

Das folgende Codebeispiel zeigt, wie ein Verbindungs-Ereignis-Listener festgelegt wird. Bei jedem Verbindungsereignis wird die onEvent -Methode des Ereignis-Listeners von der Client-Laufzeit aufgerufen.

//MQ-Verbindungsfactory erstellen.

com.sun.messaging.ConnectionFactory factory =
        new com.sun.messaging.ConnectionFactory();

//MQ-Verbindung erstellen.

com.sun.messaging.jms.Connection connection = 
       (com.sun.messaging.jms.Connection )factory.createConnection();

//MQ -Ereignis-Listener erstellen. Der Listener implementiert
//com.sun.messaging.jms.notification.EventListener-Schnittstelle.

com.sun.messaging.jms.notification.EventListener eListener = 
       new ApplicationEventListener();

//Ereignis-Listener für MQ-Verbindung festlegen.

connection.setEventListener ( eListener );

Beispiele für Ereignis-Listener

In diesem Beispiel erfasst der Ereignis-Listener der Anwendung das Verbindungsereignis im Protokollsystem der Anwendung:

public class ApplicationEventListener implementiert
				com.sun.messaging.jms.notification.EventListener {

public void onEvent ( com.sun.messaging.jms.notification.Event connEvent ) {
      	log (connEvent);
}
private void log ( com.sun.messaging.jms.notification.Event connEvent ) {
	      String eventCode = connEvent.getEventCode(); 
      	String eventMessage = connEvent.getEventMessage();
    	  //Ereignisinformationen in den Ausgabe-Stream schreiben
     	}
}