Kapitel 1 Versionshinweise zu Sun Java System Message Queue 4.2

Version 4.2

Teilenr. 820-3701

Diese Versionshinweise enthalten wichtige Informationen, die zum Zeitpunkt der Herausgabe von Sun Java™ System Message Queue 4.2 zur Verfügung standen. Hier finden Sie u. a. Informationen zu neuen Funktionen, Verbesserungen und bekannten Problemen. Lesen Sie dieses Dokument, bevor Sie Message Queue 4.2 verwenden.

Diese Versionshinweise enthalten auch Informationen über die Versionen 4.0 und 4.1 von Message Queue: unter Neue Funktionen in Message Queue 4.0 bzw. Neue Funktionen in Message Queue 4.1 finden Sie Informationen zu den in diesen Versionen neu hinzugekommenen Funktionen.

Die neueste Ausgabe dieser Versionshinweise wird auf der Sun Java System Message Queue Dokumentations-Website, unter http://docs.sun.com/coll/1307.3, bereitgestellt. Besuchen Sie diese Website vor der Installation und Konfiguration Ihrer Software und später regelmäßig, um stets die neuesten Versionshinweise und Produktdokumentationen verfügbar zu haben.

In diesen Versionshinweisen werden die folgenden Themen behandelt:

• Änderungsprotokoll der Versionshinweise

• Installation von bzw. Aufrüsten auf Message Queue 4.2

• Message Queue 4.2 - Unterstützte Plattformen und Komponenten

• Neue Funktionen in Message Queue 4.2 und aktuellen Versionen

• Funktion ist in zukünftiger Version veraltet

• In Message Queue 4.2 und aktuellen Versionen behobene Fehler

• Dokumentationsaktualisierungen in Message Queue 4.2

• Bekannte Probleme und Beschränkungen

• Dateien für Neuverteilung

• Eingabehilfen für Personen mit Behinderungen

• Problemmeldungen und Feedback

• Ihre Meinung ist gefragt

• Weitere Quellen von Sun

Diese Dokumentation nimmt Bezug auf URLs zu Produkten von Drittanbietern und bietet weitere relevante Informationen.

Sun ist nicht für die Verfügbarkeit der in diesem Dokument erwähnten Websites anderer Hersteller verantwortlich. Sun haftet nicht für den Inhalt oder Werbung auf diesen Websites oder für die auf diesen Websites angebotenen Produkte und Materialien. Sun übernimmt keine Verantwortung oder Haftung für tatsächliche oder angebliche Schäden oder Verluste, die im Zusammenhang mit den auf diesen Websites angebotenen Informationen, Waren oder Dienstleistungen entstanden sind.

Änderungsprotokoll der Versionshinweise

In der folgenden Tabelle sind die Datumsangaben zu den 4.x-Versionen von Message Queue sowie die in diesem Dokument enthaltenen Änderungen bei den einzelnen Versionen aufgeführt.

Installation von bzw. Aufrüsten auf Message Queue 4.2

Mithilfe des Message Queue 4.2-Installationsprogramms können Sie eine Neuinstallation von Message Queue 4.2 oder eine Aufrüstung von Message Queue 3.6 oder höher durchführen. Das Verfahren und alle anderen Informationen, die für Installation oder Aufrüstung auf den Plattformen Solaris, Linux und Windows relevant sind, werden im Handbuch Sun Java System Message Queue 4.2 Installation Guide dokumentiert, der noch nicht für Message Queue 4.2 aktualisiert wurde.

Wenn Sie eine Aufrüstung von einer Message Queue-Version vor 3.6 durchführen möchten, lesen Sie im Sun Java Enterprise System 5-Aufrüstungshandbuch für UNIX, Sun Java Enterprise System 5 Update 1 Upgrade Guide for UNIX nach.

Lesen Sie auch unter Installationsprobleme nach. Dort sind bekannte Probleme und Einschränkungen beschrieben, die bei Installation und Aufrüstung gelten.

Message Queue 4.2 - Unterstützte Plattformen und Komponenten

In diesem Abschnitt werden folgende Themen in Bezug auf die für Message Queue 4.2 geltenden Systemvoraussetzungen behandelt:

• Unterstütze Betriebssystemplattformen

• Unterstützung der Systemvirtualisierung

• Komponentenabhängigkeiten

Unterstütze Betriebssystemplattformen

Message Queue 4.2 wird auf den Betriebssystemplattformen Solaris, Linux und Windows unterstützt. In Tabelle 1–2 finden Sie die unterstützten Versionen dieser Plattformen. Die für die einzelnen Plattformen geltenden Hardware-Anforderungen finden Sie im Sun Java System Message Queue 4.2 Installation Guide

Unterstützung der Systemvirtualisierung

Bei der Systemvirtualisierung handelt es sich um eine Technologie, mit der mehrere Instanzen eines Betriebssystems auf einer gemeinsam genutzten Hardware unabhängig voneinander ausgeführt werden können. Auf der Funktionsebene erkennt die auf einem Betriebssystem in einer virtualisierten Umgebung bereitgestellte Software im Allgemeinen nicht, dass die zugrunde liegende Plattform virtualisiert wurde. Sun testet seine Sun Java System-Produkte auf ausgewählten Systemvirtualisierungs- und Betriebssystemkombinationen, um sicherzustellen, dass diese Produkte in virtualisierten Umgebungen mit zulässiger Größe und Konfiguration weiterhin so arbeiten wie auf nicht virtualisierten Systemen. Weitere Informationen über die Unterstützung von Sun für Sun Java System-Produkte in virtualisierten Umgebungen finden Sie unter http://download.oracle.com/820-4651.

Komponentenabhängigkeiten

Neben den plattformspezifischen Anforderungen hängt Message Queue 4.2 auch von bestimmten Grundkomponenten ab, die installiert sein müssen, damit Message Queue-Clients entwickelt und ausgeführt werden können. In Tabelle 1–3 werden diese Komponenten beschrieben. Andere Versionen oder Herstellerimplementierungen können auch verwendet werden. Diese sind jedoch von Sun Microsystems nicht getestet und werden daher nicht offiziell unterstützt.

Mit dem Message Queue-Installationsprogramm können Sie ein(e) bestehende(s) JDK/JRE auswählen, oder die JDK-Version (1.5.0_15) installieren.

In Tabelle 1–4 finden Sie zusätzliche Komponenten, die Sie installieren können, um weitere Unterstützung für Message Queue-Clients bereitzustellen. Sie benötigen nicht unbedingt alle aufgeführten Komponenten: Wenn Sie beispielsweise keinen C-Client schreiben, benötigen Sie den C-Compiler, die C++-Laufzeitbibliothek, NSPR und NSS nicht.

Neue Funktionen in Message Queue 4.2 und aktuellen Versionen

Die neuen Funktionen in Message Queue 4.2, 4.2 und 4.0 sind in folgenden Abschnitten beschrieben:

• Neue Funktionen in Message Queue 4.2

• Neue Funktionen in Message Queue 4.1

• Neue Funktionen in Message Queue 4.0

Neue Funktionen in Message Queue 4.2

Sun Java System Message Queue ist ein leistungsfähiger Nachrichtendienst, der ein zuverlässiges, asynchrones Messaging gemäß JMS 1.1 (Java Messaging Specification) bietet. Zusätzlich stellt Message Queue Funktionen bereit, die über die JMS-Spezifikation hinausgehen, um den Anforderungen großer Bereitstellungen im Unternehmensbereich gerecht zu werden.

Message Queue 4.2 ist eine Unterversion, die eine Anzahl von Funktionserweiterungen und Fehlerkorrekturen enthält. In diesem Abschnitt wird die Installation von bzw. die Aufrüstung auf Message Queue 4.2 erläutert und die neuen Funktionen, die in dieser Version enthalten sind, werden beschrieben:

• Mehrere Ziele für einen Herausgeber bzw. Abonnenten

• Schemavalidierung von XML-Payload-Meldungen

• C-API-Unterstützung für verteilte Transaktionen

• Unterstützung des Installationsprogramms für Sun Connection-Registrierung

• Unterstützung für MySQL-Datenbank

Informationen zu den in den Versionen Message Queue 4.0 und 4.1 neu hinzugekommenen Funktionen finden Sie in Neue Funktionen in Message Queue 4.0 bzw. Neue Funktionen in Message Queue 4.1.

Mehrere Ziele für einen Herausgeber bzw. Abonnenten

In Message Queue 4.2 kann ein Herausgeber nun Nachrichten an mehrere Themenziele veröffentlichen und ein Abonnent kann Nachrichten von mehreren Themenzielen konsumieren. Diese Fähigkeit wird erreicht, indem ein Themenzielname mit Platzhalterzeichen verwendet wird, der für mehrere Ziele steht. Durch die Verwendung dieser symbolischen Namen können die Administratoren bei Bedarf zusätzliche Themenziele erstellen, die dem Benennungsschema mit Platzhaltern entsprechen. Die hinzugefügten Ziele werden automatisch bei Veröffentlichungen durch Herausgeber und beim Konsum durch Abonnenten berücksichtigt. (Bei Abonnenten sind Themen mit Platzhalterzeichen üblicher als bei Herausgebern.)

Diese Funktion gilt nicht für Warteschlangenziele.

Das Format des symbolischen Themenzielnamens besteht aus mehreren Segmenten, bei denen Platzhalterzeichen (*, **, >) für ein oder mehrere Namenssegmente stehen können. Beispiel: Angenommen Sie verwenden folgendes Benennungsschema für Themenziele:

Größe verwendet wird.Farbe. Form

Dabei können die Themennamensegmente folgende Werte aufweisen:

• Größe: large, medium, small, ...

• Farbe: red, green, blue, ...

• Form: circle, triangle, square, ...

Die Nachrichtenwarteschlange unterstützt folgende Platzhalterzeichen:

• * steht für ein einzelnes Segment

• ** steht für ein oder mehrere Segmente

• > Steht für eine beliebige Anzahl aufeinander folgender Segmente

Sie können daher mehrere Themenziele wie folgt angeben:

large.*.circle steht für:

large.red.circle
large.green.circle
...

**.square steht für alle Namen, die auf .square enden, z. B.:

small.green.square
medium.blue.square
...

small.> steht für alle Zielnamen, die mit small. beginnen, z. B.:

small.blue.circle
small.red.square
...

Um diese Funktion für mehrere Ziele zu verwenden, erstellen Sie Themenziele mit einem ähnlichen Benennungsschema wie oben beschrieben. Die Client-Anwendungen können dann Herausgeber oder Konsumenten mithilfe von symbolischen Zielnamen erstellen. Beispiel:

...
String DEST_LOOKUP_NAME = "large.*.circle";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicPublisher myPublisher = mySession.createPublisher(t)
myPublisher.send(myMessage);

...
String DEST_LOOKUP_NAME = "**.square";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicSubscriber mySubscriber = mySession.createSubscriber(t);
Message m = mySubscriber.receive();

Im ersten Beispiel legt der Broker eine Kopie der Nachricht an einem Ziel ab, das dem symbolischen Namen large.*.circle entspricht. Im zweiten Beispiel wird ein Abonnement erstellt, wenn es mindestens ein Ziel gibt, das mit dem symbolischen Namen **.square übereinstimmt, und der Abonnement erhält Nachrichten aus allen Zielen, die mit diesem symbolischen Namen übereinstimmen. Wenn es keine Ziele gibt, die mit dem symbolischen Namen übereinstimmen, wird der Abonnent erst erstell, wenn ein solches Ziel vorhanden ist.

Wenn ein Administrator zusätzliche Ziele erstellt, die mit einem symbolischen Namen übereinstimmen, veröffentlichen die Platzhalter-Herausgeber, die mit diesem symbolischen Namen erstellt wurden, anschließend unter diesem Ziel, und die Platzhalter-Abonnenten, die mit diesem symbolischen Namen erstellt wurden, empfangen anschließend Nachrichten von diesem Ziel.

Außerdem melden die Message Queue-Verwaltungswerkzeuge, neben der Gesamtzahl an Herausgebern (Produzenten) und Abonnenten (Konsumenten) für ein Themenziel auch die Anzahl der Herausgeber, bei denen es sich um Platzhalter-Herausgeber handelt (einschließlich der zugehörigen symbolischen Zielnamen) und die Anzahl der Abonnenten, bei denen es sich um Platzhalter-Abonnenten handelt (einschließlich der symbolischen Zielnamen), sofern vorhanden.

Schemavalidierung von XML-Payload-Meldungen

Diese neue Funktion in Message Queue 4.2 ermöglicht die Validierung des Inhalts einer Text-XML-Nachricht (keine Objektnachrichten) anhand eines XML-Schemas an der Stelle, an der die Nachricht an den Broker gesendet wird. Der Speicherort des XML-Schemas (XSD) wird als Eigenschaft eines Message Queue-Ziels angegeben. Wenn kein XSD-Speicherort angegeben wurde, wird die DTD-Deklaration innerhalb des XML-Dokuments zur Durchführung der DTD-Validierung verwendet. (XSD-Validierung, die Datentyp und Wertebereichsvalidierung beinhaltet, ist strenger als DTD-Validierung.)

Client-Anwendungen, die diese neue Funktion verwenden, sollten die Java SE-Version auf JRE 1.5 oder höher aufrüsten.

Zur Aktivierung der XML-Schemavalidierung legen sie folgende Eigenschaften für das physische Ziel fest:

Wenn die XML-Validierung aktiviert ist, versucht die Message Queue-Client-Laufzeit, eine XML-Nachricht anhand der angegebenen XSDs (oder anhand des DTD, wenn kein XSD angegeben wurde) zu validieren, bevor sie an den Broker gesendet wird. Wenn das angegebene Schema nicht gefunden oder die Nachricht nicht validiert werden kann, wird die Nachricht nicht gesendet, und eine Ausnahme wird ausgelöst.

Die XML-Validierungseigenschaften können mit dem Befehl imqcmd create dst bwz. imqcmd update dst zum Zeitpunkt der Zielerstellung bzw. -aktualisierung festgelegt werden. Die XML-Validierungseigenschaften sollten festgelegt werden, wenn ein Ziel inaktiv ist: wenn es also keine Konsumenten und Produzenten aufweist und wenn sich keine Nachrichten in dem Ziel befinden.

Wenn ein XSD zur Laufzeit nicht zugänglich ist, kann es erforderlich sein, die XMLSchemaURIList zu bearbeiten, während ein Ziel aktiv ist.

Wenn eine der XML-Validierungseigenschaften festgelegt ist, während ein Ziel aktiv ist (beispielsweise, wenn ein Produzent mit dem Ziel verbunden ist), wird die Änderung erst wirksam, wenn der Produzent erneut eine Verbindung zum Broker herstellt. Ebenso gilt: Wenn infolge einer Änderung der Anwendungsanforderungen ein XSD geändert wird, müssen alle Client-Anwendungen, die auf der Grundlage des geänderten XSD XML-Nachrichten erstellen, erneut eine Verbindung zum Broker herstellen.

Wenn die Eigenschaft reloadXMLSchemaOnFailure auf true (wahr) gesetzt wird und die XML-Validierung fehlschlägt, versucht die Message Queue-Client-Laufzeit, das XSD erneut zu laden, bevor der erneute Versuch unternommen wird, eine Nachricht zu validieren. Die Client-Laufzeit löst eine Ausnahme aus, wenn die Validierung mithilfe der neu geladenen SXD fehlschlägt.

C-API-Unterstützung für verteilte Transaktionen

Gemäß dem verteilten Transaktionsmodell von X/Open beruht die Unterstützung für Transaktionen auf einem Manager für verteilte Transaktionen, der die von einer oder mehreren Ressourcenmanagern durchgeführten Vorgänge aufzeichnet und verwaltet. In Message Queue 4.2 unterstützt Message Queue C-API nun die XA-Schnittstelle (zwischen einem Manager für verteilte Transaktionen und Message Queue als XA-konformen Ressourcenmanager), was es Message Queue C-API-Clients, die in einer Umgebung ausgeführt werden, die verteilte Transaktionen verarbeitet (wie beispielsweise BEA Tuxedo), sich an verteilten Transaktionen zu beteiligen.

Diese Unterstützung für verteilte Transaktionen besteht aus folgenden neuen C-AP-Funktionen (und neuen Parametern und Fehlercodes), die zur Implementierung der XA-Schnittstellenspezifikation verwendet werden:

MQGetXAConnection()
MQCreateXASession()

Wenn eine C-Client-Anwendung im Kontext einer verteilten Transaktion verwendet werden soll, muss sie mithilfe von MQGetXAConnection() eine Verbindung herstellen und mithilfe von MQCreateXASession() eine Sitzung für Produktion und Konsum von Nachrichten erstellen. . Starten, Übernehmen und Zurücksetzen von verteilten Transaktionen wird durch APIs verwaltet, die vom Manager für verteilte Transaktionen bereitgestellt werden.

Öffentliche Informationen

Für de X/Open-XA-Schnittstellenspezifikation sind folgende öffentlichen Informationen in Bezug auf den XA-konformen Message Queue-Ressourcenmanager erforderlich:

• Name der xa_switch_t-Struktur: sun_my_xa_switch

• Name des Ressourcenmanagers: SUN_RM

• Die zu verknüpfende MQ C-API-Bibliothek: mqcrt

• Zeichenfolge xa_close und Format: none

• Zeichenfolge xa_open und Format: durch “;” getrennte Name=Wert-Paare

Folgende Name/Wert-Paare werden unterstützt:

Programmierungsbeispiele

Um eine Anwendung zu programmieren, die verteilte Transaktionen verwendet, erstellen Sie einen serverseitigen Dienst, der in der Umgebung des Transaktionsmanagers ausgeführt wird, und einen clientseitigen COde, der die Transaktionsmanager-APIs aufruft. Message Queue 4.2 bietet Programmierungsbeispiele, die auf dem Tuxedo-Transaktionsmanager beruhen. Diese Beispiele befinden sich im Beispielprogrammverzeichnis auf den einzelnen Plattformen im Verzeichnis ./C/tuxedo.

Dieses Verzeichnis beinhaltet eine README-Datei, die erläutert, wie Tuxedo zur Verwendung des Message Queue-Ressourcenmanagers eingerichtet wird und wie die folgenden Beispielprogramme in der Tuxedo-Umgebung erstellt werden können:

Unterstützung des Installationsprogramms für Sun Connection-Registrierung

Das Message Queue-Installationsprogramm wurde erweitert und ermöglicht nun die Registrierung von Message Queue bei Sun Connection, einem von Sun gehosteten Dienst, mit dem Sie Sun-Hardware und -Software aufzeichnen, organisieren und warten können.

Im Rahmen der Message Queue-Installation können Sie Message Queue bei Sun Connection registrieren lassen. Informationen zur installierten Message Queue, wie beispielsweise Release-Version, Hostname Betriebssystem, Installationsdatum und ähnliche grundlegende Informationen werden sicher an die Sun Connection-Datenbank übertragen. Dere Sun Connection-Inventardienst kann Sie bei der Organisation Ihrer Hard- und Software von Sun unterstützen, während der Aktualisierungsdienst Sie über die aktuellsten Sicherheitsfixes, empfohlene Updates und Funktionserweiterungen informieren kann.

der folgende Bildschirm des Installationsprogramms wurde für die Sun Connection-Registrierung zu Message Queue 4.2 hinzugefügt:

Für die Registrierung müssen Sie ein Sun Online-Konto besitzen bzw. erstellen. Wenn Sie noch nicht über ein Konto verfügen, zeigt das Installationsprogramm folgenden Bildschirm zur Erstellung eines Sun Online-Kontos an:

Sie können mithilfe der oben angegebenen Bildschirm Message Queue während der Installation erstellen oder bis zum Abschluss der Installation warten und das Installationsprogramm wie folgt im reinen Registrierungsmodus ausführen:

# installer -r

Für den reinen Registrierungsmodus muss Message Queue 4.2 bereits installiert sein und zeigt nur die Bildschirme des Installationsprogramms an, die sich auf die Registrierung beziehen.

Unterstützung für MySQL-Datenbank

Message Queue 4.2 unterstützt MySQL-Datenbank als JDBC-basierter Datenspeicher. MySQL Cluster Edition kann als JDBC-Datenbank für einen eigenständigen Broker verwendet werden, und MySQL Cluster Edition kann als hochverfügbarer gemeinsam genutzter Datenspeicher verwendet werden, der für einen Hochverfügbarkeits-Broker-Cluster benötigt wird. Informationen zur Konfiguration von Message Queue für die Verwendung von MySQL finden Sie unter Configuring a JDBC-Based Data Store in Sun Java System Message Queue 4.2 Administration Guide sowie unter High-Availability Cluster Properties in Sun Java System Message Queue 4.2 Administration Guide.

Neue Funktionen in Message Queue 4.1

Message Queue 4.1 war eine Unterversion, die eine Reihe neuer Funktionen, einige Funktionserweiterungen und Fehlerkorrekturen enthielt. In diesem Abschnitt werden die neuen Funktionen in der Version 4.1 beschrieben und weitere Referenzen für Ihre Verwendung angegeben:

• Hochverfügbarkeits-Broker-Cluster

• JAAS-Unterstützung

• Formatänderung für persistenten Datenspeicher

• Broker-Umgebungs-Konfiguration

• Unterstützung für Java ES Monitoring Framework

• Erweiterte Transaktionsverwaltung

• Feste Ports für C-Clientverbindungen

Informationen zu den in Message Queue 4.0 hinzugefügten Funktionen finden Sie unter Neue Funktionen in Message Queue 4.0.

Hochverfügbarkeits-Broker-Cluster

In Message Queue 4.1 kamen Hochverfügbarkeits-Broker-Cluster neu hinzu. Im Vergleich zu konventionellen Broker Clustern, die nur Nachrichtendienst-Verfügbarkeit (wenn ein Broker ausfällt, ist ein anderer verfügbar, um den Nachrichtendienst bereitzustellen) bieten, bieten Hochverfügbarkeits-Broker-Cluster auch Daten-Verfügbarkeit (wenn ein Broker ausfällt, stehen seine persistenten Meldungen und Statusdaten einem anderen Broker zur Verfügung, der sie verwenden kann, um die Nachrichtenzustellung zu übernehmen.

Die seit Message Queue 4.1 verfügbare Hochverfügbarkeits-Implementierung verwendet einen freigegebenen JDBC-basierten Datenspeicher: Anstatt dass jedes Broker-Cluster seinen eigenen persistenten Datenspeicher besitzt, verwenden alle Broker im Cluster dieselbe JDBC-konforme Datenbank. Wenn ein bestimmter Broker ausfällt, übernimmt ein anderer Broker innerhalb des Clusters die Nachrichtenweiterleitung und Zustellung für den ausgefallenen Broker. Dabei verwendet der Failover-Broker Daten und Statusinformationen aus dem gemeinsam genutzten Datenspeicher. Messaging-Clients des ausgefallenen Brokers stellen eine neue Verbindung zum Failover-Broker her, der ununterbrochenen Nachrichtendienst bietet.

Der freigegebene JDBC-basierte Speicher, der in der Message Queue 4.1-Hochverfügbarkeitsimplementierung verwendet wurde, muss ebenfalls hochverfügbar sein. Wenn Sie keine hochverfügbare Datenbank besitzen oder wenn eine unterbrechungsfreie Nachrichtenzustellung für Sie nicht von hoher Wichtigkeit ist, können Sie weiterhin konventionelle Cluster verwenden, die Dienstverfügbarkeit ohne Datenverfügbarkeit bieten.

Um einen Message Queue 4.1-Hochverfügbarkeits-Broker-Cluster zu konfigurieren, geben Sie für jeden Broker im Cluster folgende Broker-Eigenschaften an:

• Eigenschaften für die Clustermitgliedschaft. die angeben, dass der Broker Teil eines Hochverfügbarkeits-Broker-Clusters ist, und die ID des Clusters und des Brokers innerhalb des Clusters festlegen.

• Eigenschaften für hochverfügbare Datenbanken, die das persistente Datenmodell (JDBC), den Namen des Datenbankherstellers und herstellerspezifische Konfigurationseigenschaften angeben.

• Eigenschaften für Fehlererkennung und Failover, die angeben, wie ein Broker-Ausfall ermittelt und mithilfe eines Failover-Brokers behandelt wird.

Um die Implementierung mit Hochverfügbarkeits-Broker-Cluster verwenden zu können, müssen Sie folgende Schritte ausführen:

1. Installieren einer hochverfügbaren Datenbank.

2. Installieren der .jar-Datei des JDBC-Treibers.

3. Erstellen des Datenbankschemas für den hochverfügbaren persistenten Datenspeicher.

4. Festlegen der Hochverfügbarkeitseigenschaften für jeden Broker im Cluster.

5. Starten der einzelnen Broker im Cluster.

Eine Beschreibung der Konzepte im Zusammenhang mit Hochverfügbarkeits-Broker-Clustern und einen Vergleich mit konventionellen Clustern finden Sie in Kapitel 4, Broker Clusters in Sun Java System Message Queue 4.2 Technical Overview. Die Vorgehensweise und Referenzinformationen zu Hochverfügbarkeits-Broker-Clustern finden Sie in Kapitel 8, Managing Broker Clusters in Sun Java System Message Queue 4.2 Administration Guide und unter Cluster Configuration Properties in Sun Java System Message Queue 4.2 Administration Guide.

Wenn Sie eine hochverfügbare Datenbank zusammen mit Message Queue 4.0 verwendet haben und nun zu einem Hochverfügbarkeits-Broker-Cluster wechseln möchten, können Sie mit dem Datenbank-Manager-Dienstprogramm (imqdbmgr) die Konvertierung in einen gemeinsam genutzten persistenten Datenspeicher durchführen. Weitere Informationen zu Bekannten Problemen und Einschränkungen finden Sie unter Broker-Cluster.

JAAS-Unterstützung

Neben den dateibasierten und den LDAP-basierten integrierten Authentifizierungsmechanismen wurde in Message Queue 4.1 auch die Unterstützung für den Java Authentication and Authorization Service (JAAS), aufgenommen, sodass Sie einen externen Authentifizierungsmechanismus mit dem Broker verbinden können, um Message Queue-Clients zu authentifizieren.

Eine Beschreibung der Informationen, die ein Broker einem JAAS-konformen Authentifizierungsdienst zur Verfügung steht und eine Erläuterung der Konfiguration des Brokers zur Verwendung eines solchen Diensts finden Sie unter Using JAAS-Based Authentication in Sun Java System Message Queue 4.2 Administration Guide.

Formatänderung für persistenten Datenspeicher

Message Queue 4.1änderte den JDBC-basierten Datenspeicher dahingehend, dass Hochverfügbarkeits-Broker-Cluster unterstützt werden. Aus diesem Grund wird das Format des JDBC—basierten Datenspeichers auf Version 410 erhöht. Die Formatversionen 350, 370 und 400 werden automatisch auf die Version 410 erhöht.

Beachten Sie, dass das Format des dateibasierten persistenten Datenspeichers auf Version 370 verbleibt, da daran keine Änderungen vorgenommen wurden.

Broker-Umgebungs-Konfiguration

Die Eigenschaft IMQ_DEFAULT_EXT_JARS wurde in die Umgebungskonfigurationsdatei von Message Queue 4.1, imqenv.conf, aufgenommen. Sie können diese Eigenschaft festlegen, um die Pfadnamen externer .jar-Dateien anzugeben, die beim Start des Brokers in CLASSPATH aufgenommen werden sollen. Wenn Sie diese Eigenschaft verwenden, um den Speicherort von externen .jar-Dateien anzugeben, müssen Sie diese Dateien nicht mehr in das Verzeichnis lib/ext kopieren. Externe .jar-Dateien können sich auf JDBC-Treiber oder JAAS-Anmeldemodule beziehen. Die folgende Beispieleigenschaft gibt den Speicherort von JDBC-Treibern an.

IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar

Unterstützung für Java ES Monitoring Framework

In Message Queue 4.1 wurde Unterstützung für das Sun Java Enterprise System (Java ES) Monitoring Framework aufgenommen, mit dem Java ES-Komponenten mithilfe einer üblichen grafischen Oberfläche überwacht werden können. Diese Oberfläche wird durch die webbasierte Sun Java System Monitoring Console implementiert. Administratoren können mit der Konsole Leistungsstatistiken anzeigen, Regeln für die automatische Überwachung erstellen und Alarme bestätigen. Wenn Sie Message Queue gemeinsam mit anderen Java ES-Komponenten ausführen, ist es möglicherweise praktischer, eine einzige Oberfläche zur Verwaltung all dieser Komponenten zu verwenden.

Informationen zur Verwendung des Java ES Monitoring Framework zur Überwachung von Message Queue finden Sie unter XREF.

Erweiterte Transaktionsverwaltung

Zuvor konnte ein Administrator nur für Transaktionen mit dem Status PREPARED ein Rollback ausführen. Das heißt, dass beim nicht ordnungsgemäßen Beenden einer Sitzung, die Teil einer verteilten Transaktion war, für die Transaktion ein Status beibehalten wurde, der nicht durch einen Administrator bereinigt werden konnte. In Message Queue 4.1 können Sie nun mit dem Befehlsdienstprogramm (imqcmd) Transaktionen bereinigen (in einem Rollback zurücksetzen), die folgende Statuswerte aufweisen: STARTED, FAILED, INCOMPLETE, COMPLETE und PREPARED.

Um zu ermitteln, ob für eine bestimmte Transaktion ein Rollback durchgeführt werden kann (insbesondere, wenn diese nicht den Status PREPARED aufweist), bietet das Befehlsdienstprogramm zusätzliche Daten als Teil der imqcmd query txn-Ausgabe: Es stellt die Verbindungs-ID für die Verbindung bereit, welche die Transaktion gestartet hat, und gibt die Uhrzeit an, zu welcher die Transaktion erstellt wurde. Mithilfe dieser Informationen kann ein Administrator ermitteln, ob für die Transaktion ein Rollback durchgeführt werden muss. Im Allgemeinen sollte der Administrator ein zu frühes Rollback für eine Transaktion vermeiden.

Feste Ports für C-Clientverbindungen

In Message Queue 4.1 können C-Clients nun ebenso wie Java-Clients eine Verbindung mit einem festen Broker-Anschluss herstellen und müssen nicht mehr eine Verbindung zu einem Anschluss herstellen, der dynamisch vom Portmapper-Dienst des Brokers zugewiesen wurde. Feste Anschlussverbindungen sind nützlich, wenn Sie versuchen, eine Firewall zu überwinden, oder wenn Sie den Portmapper-Dienst aus einem anderen Grund umgehen müssen.

Zur Konfiguration einer festen Anschlussverbindung müssen Sie sowohl den Broker als auch die Laufzeit des C-Client (beide Enden der Verbindung) konfigurieren. Wenn Sie Ihren Client z. B. über ssljms mit Anschluss1756 verbinden möchten, führen Sie die folgenden Schritte aus.

• Legen Sie auf der Client-Seite folgende Eigenschaften fest:

  MQ_SERVICE_PORT_PROPERTY=1756

  MQ_CONNECTION_TYPE_PROPERTY=SSL

• Legen Sie auf der Broker-Seite die Eigenschaft imq.serviceName.protocolType .port wie folgt fest:

  imq.ssljms.tls.port=1756

Die Verbindungseigenschaft MQ_SERVICE_PORT_PROPERTY wurde durch Backporting auf Message Queue 3.7 Update 2 übertragen.

Neue Funktionen in Message Queue 4.0

Message Queue 4.0 war eine Unterversion, die auf die Unterstützung von Application Server 9 PE beschränkt war. Sie beinhaltete einige neue Funktionen sowie einige Funktionserweiterungen und Fehlerbehebungen. Dieser Abschnitt enthält eine Beschreibung neuer Funktionen in dieser Version:

• Unterstützung für JMX Administration API

• Protokollierung zur Client-Laufzeit

• Verbindungsereignisbenachrichtigungs-API

• Erweiterungen der Broker-Administration

• Anzeigen von Informationen zu einem JDBC-basierten Datenspeicher

• JDBC-Anbieter-Unterstüztung

• Formatänderungen für persistenten Datenspeicher

• Zusätzliche Nachrichteneigenschaften

• SSL-Unterstützung

Eine der 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. Ab dieser Version müssen Sie alle Passwörter in einer Datei speichern, wie in Veraltete Passwortoption beschrieben, oder Sie bei Aufforderung eingeben.

Unterstützung für JMX Administration API

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 Java-Client-Anwendung zu konfigurieren und zu überwachen. In früheren Versionen von Message Queue war der Zugriff auf diese Funktionen ausschließlich über die Administrationsdienstprogramme der Befehlszeile oder die Administrationskonsole möglich.

Weitere Informationen finden Sie im Sun Java System Message Queue 4.2 Developer’s Guide for JMX Clients.

Protokollierung zur Client-Laufzeit

In Message Queue 4.0 wurde Unterstützung für Client-Laufzeitprotokollierung von verbindungs- und sitzungsbezogenen Ereignissen eingeführt.

Weitere Informationen zur Client-Laufzeitprotokollierung und ihrer Konfiguration finden Sie im Java Dev Guide auf Seite 137.

Verbindungsereignisbenachrichtigungs-API

In Message Queue 4.0 wurde eine Ereignisbenachrichtigungs-API eingeführt, mit der die Client-Laufzeit eine Anwendung über Änderungen im Verbindungsstatus informieren kann. Verbindungsereignisbenachrichtigungen ermöglichen es 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.

Informationen zu Verbindungsereignissen und zum Erstellen einer Ereignisüberwachungsfunktion finden Sie im Java Dev Guide auf Seite 96.

Erweiterungen der Broker-Administration

In Message Queue 4.0 wurden ein neuer Unterbefehl und mehrere Befehlsoptionen zum Befehlsdienstprogrammm (imqcmd) hinzugefügt, um es Administratoren zu ermöglichen, einen Broker stillzulegen (zu inaktivieren), einen Broker nach einem angegebenen Zeitraum herunterzufahren, eine Verbindung zu vernichten oder Java-Systemeigenschaften (z. B. Verbindungsbezogene Eigenschaften) festzulegen.

• Bei der Stilllegung (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. Zum 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-Broker-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.2 Administration Guide.

Anzeigen von Informationen zu einem JDBC-basierten Datenspeicher

In Message Queue 4.0 wurde ein neuer Unterbefehl query zum Datenbank-Manager-Dienstprogramm, imqdbmgr, hinzugefügt. Dieser Unterbefehl wird zum Anzeigen von Informationen zu einem JDBC-basierten Datenspeicher (u. a. Datenbankversion, Datenbankbenutzer und ob die Datenbanktabellen erstellt wurden) verwendet.

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.

JDBC-Anbieter-Unterstüztung

In Message Queue 4.0 wird nun Apache Derby Version 10.1.1 als JDBC-basierter Datenspeicheranbieter unterstützt.

Formatänderungen für persistenten Datenspeicher

Message Queue 4.0 führte Änderungen am JDBC-basierten Datenspeicher zur Optimierung und zur Unterstützung zukünftiger Erweiterungen ein. Aus diesem Grund wurde das Format des JDBC-basierten Datenspeichers auf Version 400 erhöht. Beachten Sie, dass bei Message Queue 4.0 die Version des dateibasierten Datenspeichers weiterhin 370 ist, da keine Änderungen daran vorgenommen wurden.

Zusätzliche Nachrichteneigenschaften

Message Queue 4.0 fügte zwei neue Eigenschaften hinzu, die für alle Nachrichten festgelegt werden, die in die Warteschlange für nicht zugestellte Nachrichten eingestellt werden.

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

SSL-Unterstützung

Ab Message Queue 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 Befehlsdienstprogramm (imqcmd) sicher zu verwenden, wenn der Broker selbstignierte Zertifikate verwendet, müssen Sie einen Befehl wie den folgenden (zur Auflistung der Konnectorservices) verwenden.

imqcmd list svc -secure -DimqSSLIsHostTrusted=true

Funktion ist in zukünftiger Version veraltet

Nachrichtenbasierte Überwachung, mit der Sie einen Broker uns seine Ziele mithilfe von Metrikinformationen überwachen können, die in Metrik-Themenziele geschrieben sind, wird in zukünftigen Versionen nicht mehr verwendet.

Die nachrichtenbasierte Überwachung nutzt den konfigurierbaren Metrics Message Producer, um Metrikdaten in JMS-Nachrichten zu schreiben, die anschließend in Abhängigkeit vom Typ der in den Nachrichten enthaltenen Metrikinformationen an Metrik-Themenziele gesendet werden. Der Zugriff auf diese Metrikinformationen erfolgt dann durch Schreiben einer Client-Anwendung, die das entsprechende Metrik-Themenziel abonniert, die zugehörigen Nachrichten konsumiert und die Daten wie festgelegt verarbeitet.

Die nachrichtenbasierte Überwachungsfunktion wurde durch die JMX Administration API ersetzt, die in MQ 4.0 implementiert wurde (siehe Unterstützung für JMX Administration API). Die JMX API ist umfassender (sie enthält mehr Metrikdaten als an die Themenziele gesendet werden) und beruht auf dem Industriestandard JMX.

Es gibt keinen zwingenden Grund zur Verwendung der nachrichtenbasierten Überwachung, nun da Message Queue die JMX API unterstützt. Informationen zur nachrichtenbasierten Überwachung bleiben in der Message Queue-Dokumentation erhalten, bis die Funktion formal verworfen wurde.

In Message Queue 4.2 und aktuellen Versionen behobene Fehler

Message Queue 4.2 beinhaltet neue Fehlerkorrekturen und berücksichtigt auch Fehler, die in den Versionen Message Queue 4.1und Message Queue 4.0 behoben wurden.

In den folgenden Abschnitten werden Fehler aufgeführt, die in den jeweiligen Versionen behoben wurden:

• In Message Queue 4.2 behobene Fehler

• In Message Queue 4.1 behobene Fehler

• Behobene Probleme in Message Queue 4.0

In Message Queue 4.2 behobene Fehler

In der folgenden Tabelle sind die in Message Queue 4.2 behobenen Fehler aufgelistet.

Die folgende Tabelle sollte die nennenswerten Fehler enthalten, die in 4.1 Patch 1 und 4.1 Patch 2 behoben wurden. Ich brauche Hilfe bei der Ermittlung dieser Fehler. Gibt es darüber hinaus weitere Fehlerkorrekturen, die die soeben erwähnten nicht beinhalten?

In Message Queue 4.1 behobene Fehler

In der folgenden Tabelle sind die in Message Queue 4.1 behobenen Fehler aufgelistet.

Behobene Probleme in Message Queue 4.0

In der folgenden Tabelle sind die in Message Queue 4.0 behobenen Probleme aufgelistet.

Dokumentationsaktualisierungen in Message Queue 4.2

Dieser Abschnitt enthält Informationen zu Dokumentationsaktualisierungen in Message Queue 4.2:

• Kompatibilitätsprobleme

• Änderungen am Message Queue 4.2-Dokumentationssatz

• Neue Zielmetrik

• Automatischer Broker-Start unter Solaris 10 OS

• Änderungen an der JMX-API

• Unterstützung für DN-Benutzernamensformat für Client-Authentifizierung

• Erweiterung zur JAAS-Authentifizierung

Kompatibilitätsprobleme

In diesem Abschnitt werden bekannte Kompatibilitätsprobleme in Bezug auf Message Queue 4.2 beschrieben.

Schnittstellenstabilität

Sun Java System Message Queue verwendet zahlreiche Schnittstellen, die sich mit der Zeit ändern können. Eine Klassifizierung der Schnittstellen nach ihrer Stabilität finden Sie in Anhang B, Stability of Message Queue Interfaces in Sun Java System Message Queue 4.2 Administration Guide. Je stabiler eine Schnittstelle, desto weniger wahrscheinlich ist eine Änderung in den nachfolgenden Produktversionen.

Mögliche Probleme hinsichtlich der nächsten Hauptversion von Message Queue

Die nächste Hauptversion von Message Queue umfasst eventuell Änderungen, die eine Inkompatibilität mit den aktuellen Message Queue-Client-Anwendungen verursachen können. Diese Informationen werden im Interesse einer vollständigen Offenlegung angegeben.

• Die Speicherorte einzelner Dateien, die als Bestandteil von Sun Java System Message Queue installiert werden, kann sich ändern. Dadurch können in vorhandenen Anwendungen Fehler auftreten, die vom aktuellen Speicherort bestimmter Message Queue-Dateien abhängen.

• Broker der Version Message Queue 3.5 oder niedrigere Versionen können in einem Cluster mit neueren Brokern möglicherweise nicht mehr eingesetzt werden.

• In zukünftigen Versionen ist die Verwendung von früheren JDK-Versionen als 1.5 in Message Queue-Clients eventuell nicht mehr möglich.

• In zukünftigen Versionen ist die Verwendung von früheren JDK-Versionen als 1.6 in Message Queue-Clients eventuell nicht mehr möglich.

Änderungen am Message Queue 4.2-Dokumentationssatz

Der Message Queue 4.2-Dokumentationssatz enthält Aktualisierungen für den Message Queue 4.1-Dokumentationssatz, wie unten beschrieben:

Technischer Überblick

Das Handbuch Sun Java System Message Queue 4.2 Installation Guide wurde aktualisiert und berücksichtigt nun die neuen Funktionen in Message Queue 4.2 und ein aktualisiertes Framework für Hochverfügbarkeits-Broker-Cluster.

Administration Guide

Das Handbuch Administration Guide wurde aktualisiert und berücksichtigt nun die neuen Funktionen in Message Queue 4.2.

Installations- und Upgradeinformationen

Das Handbuch Sun Java System Message Queue 4.2 Installation Guide wurde nicht zur Berücksichtigung der neuen Funktionen in Message Queue 4.2, insbesondere der Sun Connect-Registrierungsfunktion im Installationsprogramm, aktualisiert. Diese Informationen sind in den vorliegenden Message Queue - Versionshinweise enthalten

Developer's Guide for Java Clients

Das Handbuch Developer’s Guide for Java Clients wurde nicht zur Berücksichtigung der neuen Funktionen in Message Queue 4.2 aktualisiert. Diese Informationen sind in den vorliegenden Message Queue - Versionshinweise enthalten

Developer’s Guide for C Clients

Das Handbuch Developer’s Guide for C Clients wurde nicht zur Berücksichtigung der neuen Funktionen in Message Queue 4.2 aktualisiert. Diese Informationen sind in den vorliegenden Message Queue - Versionshinweise enthalten

Developer's Guide for JMX Clients

wurde nicht zur Berücksichtigung der neuen Funktionen in Message Queue 4.2 aktualisiert. Diese Informationen sind in den vorliegenden Message Queue - Versionshinweise enthalten

Neue Zielmetrik

Message Queue 4.2 beinhaltet eine neue Zielmetrik, die bei der Überwachung von Zielen in einem Broker-Cluster nützlich sein kann. In einem Broker-Cluster werden Ziele an alle Broker im Cluster weitergegeben. Nachrichten werden bei ihrer Erstellung jedoch im Ziel des Home-Brokers des Nachrichtenproduzenten gespeichert und nur dann an das entsprechende Ziel auf einem anderen Brokers im Cluster gesendet, wenn ein aktiver Konsument für dieses Ziel vorhanden ist. In Folge sind die in einem angegebenen Ziel gespeicherten Nachrichten von dem Broker in dem Cluster abhängig, in dem sich das Ziel befindet.

Anders ausgedrückt: In einem Broker-Cluster setzen sich die Nachrichten, die in einem bestimmten Ziel auf einem bestimmten Broker im Cluster gespeichert sind, aus Nachrichten zusammen, die direkt für dieses Ziel produziert wurden, und aus Nachichten, die von Remote-Brokern im Cluster am das Ziel gesendet wurden. Bei der Analyse der Nachrichtenweiterleitung und -zustellung in einem Broker-Cluster ist es zuweilen hilfreich zu wissen, wie viele Nachrichten in einem Ziel lokal (lokal produziert) und wie viele remote (remote produziert) sind.

In der folgenden Tabelle sind zwei neue metrische Größen für physische Ziele in Message Queue 4.2 dargestellt. Die neuen metrischen Größen sind über die Befehle imqcmd list dst und imqcmd query dst sowie über die neuen JMX-Attribute verfügbar (siehe Zielüberwachungs-MBean.

Automatischer Broker-Start unter Solaris 10 OS

In diesem Abschnitt wird die Konfiguration des automatischen Broker-Starts beim Betriebssystem Solaris 10 beschrieben. Anstatt eine rc-Datei zur Implementierung des automatischen Broker-Starts beim Neustart eines Computers zu implementieren, nutzt das folgende Verfahren die Solaris 10 Service Management Facility (SMF).

Weitere Informationen zur Verwendung der Service Management Facility finden Sie in der Dokumentation zu Solaris 10.

So implementieren Sie den automatischen Broker-Start unter dem Betriebssystem Solaris 10:

1. Importieren Sie den mqbroker-Dienst in das SMF-Repository.

   # svccfg import /var/svc/manifest/application/sun/mq/mqbroker.xml

2. Vergewissern Sie sich, dass der Importvorgang erfolgreich war, indem Sie den Status des mqbroker-Diensts überprüfen.

   # svcs mqbroker

   Die Ausgabe ähnelt Folgendem:

   STATE STIME FMRI disabled 16:22:50 svc:/application/sun/mq/mqbroker:default

   Der Dienst wird ursprünglich als deaktiviert angezeigt.

3. Aktivieren Sie den mqbroker-Dienst.

   # svcadm enable svc:/application/sun/mq/mqbroker:default

   Durch die Aktivierung des mqbroker-Diensts wird der Prozess imqbrokerd gestartet. Anschließend wird der Broker durch einen Neustart des Computers neu gestartet.

4. Konfigurieren Sie den mqbroker-Dienst so, dass alle gewünschten Argumente an den Befehl imqbrokerd weitergeleitet werden.

   Die Eigenschaft options/server_args wird zur Weiterleitung von Argumenten an imqbrokerd verwendet. Gehen Sie beispielsweise wie folgt vor, um -loglevel DEBUGHIGH hinzuzufügen:

   # svccfg svc:> select svc:/application/sun/mq/mqbroker svc:/application/sun/mq/mqbroker> setprop options/server_args=\"-loglevel DEBUGHIGH\" svc:/application/sun/mq/mqbroker> exit

Änderungen an der JMX-API

Message Queue unterstützt die Java Management Extensions-(JMX-)API zur programmatischen Konfiguration und Überwachung von Broker-Funktionen aus einer Message Queue-Client-Anwendung. Message Queue 4.2 beinhaltet Erweiterungen an der JMX-API zur Unterstützung neuer Funktionen und Funktionalitäten in der Version. Neue JMX-Attribute, Vorgänge und/oder Nachschlageschlüssel sind für folgende Mbeans definiert:

• ConsumerManager-Überwachungs-MBean

• Zielkonfigurations-MBean

• Zielmanager-Konfigurations-MBean

• Zielüberwachungs-MBean

• ProducerManager-Überwachungs-MBean

ConsumerManager-Überwachungs-MBean

Die Attribute, Vorgänge und Nachschlageschlüssel in folgenden Tabellen unterstützen die in Mehrere Ziele für einen Herausgeber bzw. Abonnenten beschriebene Funktion.

Der Name des folgenden Attributs ist als statische Konstante in der Dienstprogrammklasse com.sun.messaging.jms.management.server.ConsumerAttributes definiert.

Die Namen der folgenden Vorgänge sind als statische Konstanten in der Dienstprogrammklasse com.sun.messaging.jms.management.server.ConsumerOperations definiert.

Folgende Nachschlageschlüssel sind als statische Konstanten in der Dienstprogrammklasse com.sun.messaging.jms.management.server.ConsumerInfo definiert.

Zielkonfigurations-MBean

Die Attribute in der folgenden Tabelle unterstützen die in Schemavalidierung von XML-Payload-Meldungen beschriebene Funktion.

Die Namen der folgenden Attribute sind als statische Konstanten in der Dienstprogrammklasse com.sun.messaging.jms.management.server.DestinationAttributes definiert.

Zielmanager-Konfigurations-MBean

Die oben angegebenen neuen Zielkonfigurations-MBean-Attribute, die die neue Funktion, Schemavalidierung von XML-Payload-Meldungen unterstützen, können zum Erstellen eines Ziels mithilfe des Vorgangs create des Zielmanager-Konfigurations-MBean verwendet werden.

Zielüberwachungs-MBean

Der erste Attributsatz in der folgenden Tabelle unterstützt die in Mehrere Ziele für einen Herausgeber bzw. Abonnenten beschriebene Funktion und der zweite Attributsatz untersetützt die in Neue Zielmetrik beschriebene Erweiterung.

Die Namen der folgenden Attribute sind als statische Konstanten in der Dienstprogrammklasse com.sun.messaging.jms.management.server.DestinationAttributes definiert.

Die Vorgänge in der folgenden Tabelle unterstützen die in Mehrere Ziele für einen Herausgeber bzw. Abonnenten beschriebene Funktion.

Die Namen der folgenden Vorgänge sind als statische Konstanten in der Dienstprogrammklasse com.sun.messaging.jms.management.server.DestinationOperations definiert.

ProducerManager-Überwachungs-MBean

Die Attribute, Vorgänge und Nachschlageschlüssel in den unten stehenden Tabellen unterstützen die in Mehrere Ziele für einen Herausgeber bzw. Abonnenten beschriebene Funktion.

Der Name des folgenden Attributs ist als statische Konstante in der Dienstprogrammklasse com.sun.messaging.jms.management.server.ProducerAttributes definiert.

Die Namen der folgenden Vorgänge sind als statische Konstanten in der Dienstprogrammklasse com.sun.messaging.jms.management.server.ProducerOperations definiert.

The following lookup keys are defined as static constants in the utility class com.sun.messaging.jms.management.server.ProducerInfo.

Unterstützung für DN-Benutzernamensformat für Client-Authentifizierung

Message Queue 4.2 unterstützt das DN-Benutzernamensformat bei der Client-Verbindungsauthentifizierung anhand eines LDAP-Benutzer-Repositorys. Die Unterstützung beinhaltet folgende neue Broker-Eigenschaft (und Wert):

imq.user_repository.ldap.usrformat=dn

Mit dieser Eigenschaft kann der Brokert einen Client-Benutzer anhand eines Eintrags in einem LDAP-Benutzer-Repository authentifizieren, inidem aus dem DN-Benutzernamensformat der Wert des durch folgende Eigenschaft angegebenen Attributs extrahiert wird:

imq.user_repository.ldap.uidattr

Der Broker verwendet den Wert des oben angegebenen Attributs als Namen des Benutzers bei Zugriffssteuerungsvorgängen.

Wenn beispielsweise gilt: imq.user_repository.ldap.uidattr=udi und wenn ein Benutzername für die Client-Authentifizierung im Format udi=mquser,ou=People,dc=red,dc=sun,dc=com vorliegt, dann wird "mquser" zur Durchführung der Zugriffssteuerung extrahiert.

Erweiterung zur JAAS-Authentifizierung

Die JAAS-Authentifizierung von Message Queue 4.2 unterstützt Authentifizierung durch IP-Adressen sowie durch Benutzernamen.

Bekannte Probleme und Beschränkungen

In diesem Abschnitt werden die bekannten Probleme mit Message Queue 4.2 aufgeführt. Die folgenden Produktbereiche werden besprochen:

• Installationsprobleme

• Veraltete Passwortoption

• Administration/Konfiguration

• Broker-Probleme

• Broker-Cluster

• JMX-Probleme

• SOAP-Unterstützung

Eine Liste der aktuellen Fehler, deren Status und Umgehungsmöglichkeiten finden Sie als Mitglied der Java Developer Connection™ in der Bug Parade auf der Java Developer Connection-Website. Prüfen Sie die Informationen auf dieser Seite, bevor Sie einen neuen Fehler melden. Auch wenn nicht alle Message Queue-Fehler aufgelistet sind, ist diese Seite ein guter Ausgangspunkt, wenn Sie feststellen möchten, ob ein Problem bekannt gegeben wurde.

http://bugs.sun.com/bugdatabase/index.jsp

Die Mitgliedschaft bei der Java Developer Connection ist kostenlos, es ist jedoch eine Registrierung erforderlich. Auf der Sun Java-Webseite wird beschrieben, wie Sie Mitglied bei der Java Developer Connection werden.

Wenn Sie einen neuen Fehler melden oder eine Funktionsanfrage einreichen möchten, senden Sie eine E-Mail an imq-feedback@sun.com .

Installationsprobleme

In diesem Abschnitt werden die Installationsprobleme zu Message Queue Version 4.2 beschrieben.

Produktregistrierung und Java ES

Message Queue 4.2 wird ebenso wie Message Queue 4.1 von einem relativ neuen Installationsprogramm installiert, das auch zur Installation und Aufrüstung der gemeinsam genutzten Komponenten von Java Enterprise System (Java ES) dient, die von Message Queue benötigt werden, z. B.: JDK, NSS, JavaHelp usw.

Das neue Message Queue-Installationsprogramm und das ältere Java ES-Installationsprogramm, das zur Installation früherer Message Queue-Versionen verwendet wurden, verwenden nicht dieselbe Produktregistrierung. Wenn eine Message Queue-Version, die mit dem Java ES-Installationsprogramm installiert wurde, entfernt und mithilfe des Message Queue-Installationsprogramms auf Message Queue 4.2 aufgerüstet wird, ist der Status der Java ES-Produktregistrierung möglicherweise inkonsistent. Dies hat zur Folge, dass beim Ausführen des Java ES-Deinstallationsprogramms eventuell Message Queue 4.2 und die benötigten gemeinsamen Komponenten versehentlich entfernt werden, obwohl sie nicht von diesem Programm installiert wurden.

Zur Aktualisierung der Message Queue-Software, die mit dem JES-Installationsprogramm installiert wurde, gehen Sie am besten wie folgt vor.

1. Entfernen Sie mit dem Java ES-Deinstallationsprogramm Message Queue sowie die gemeinsam genutzten Komponenten.

2. Installieren Sie mit dem Message Queue-Installationsprogramm Message Queue 4.2.

Installation unter Windows

Wenn Sie Message Queue unter Windows installieren, sollten Sie die folgenden Einschränkungen beachten.

• Das Installationsprogramm fügt unter Start > Programme keine neuen Einträge für Message Queue hinzu. (Fehler 6567258)

  Umgehung: Um die Administrationskonsole zu starten, verwenden Sie die Befehlszeile, wie in Starting the Administration Console in Sun Java System Message Queue 4.2 Administration Guide beschrieben.

• Das Installationsprogramm fügt das Verzeichnis IMQ_HOME\mq\bin nicht zur PATH-Umgebungsvariable hinzu.(Fehler 6567197)

  Umgehung: Benutzer müssen entweder diesen Eintrag zur PATH-Umgebungsvariable hinzufügen oder einen vollständigen Pfadnamen angeben, wenn sie die Message Queue-Dienstprogramme (IMQ_HOME\mq\bin\Befehl) aufgerufen.

• Das Installationsprogramm fügt keine Einträge zur Windows-Registrierung hinzu, die darauf hinweisen, dass Message Queue installiert ist. (Fehler 6586389)

• Bei Installation im automatischen Modus mit einer Antwortdatei wird das Installationsprogramm sofort wieder angezeigt.. Die Installation wird zwar durchgeführt, jedoch weiß der Benutzer nicht, wann die automatische Installation tatsächlich abgeschlossen ist. (Fehler 6586560)

• Beim Versuch, das Installationsprogramm im Textmodus (installer –t ) unter Windows auszuführen, wird eine Fehlermeldung in englischer Sprache ausgegeben, auch wenn das Installationsprogramm in einer anderen Sprache als Englisch ausgeführt wird. Det Textmodus wird unter Windows nicht unterstützt. (Fehler 6594142)

• Das Installationsprogramm installiert Message Queue nicht standardmäßig auf demselben Laufwerk, auf dem das Betriebssystem installiert ist. (Fehler 6673511)

• Für die Installation und Deinstallation unter Windows gibt es keine .bat-Dateien, die der Benutzer ausführen kann, und der Benutzer kann auch die Deinstallation nicht über die Option Software in der Windows-Systemsteuerung deinstallieren. (Fehler 6673417)

• Unter Windows Vista kann Message Queue nicht unter C:\Programme installiert werden, es sei denn die Installation erfolgt als Administrator über eine Eingabeaufforderung. (Fehler 6701661)

  Umgehung: So führen Sie die Installation als Administrator über eine Befehlszeile durch:

  1. Start->Programme->Zubehör->Eingabeaufforderung.

  2. Klicken Sie mit der rechten Maustaste auf Eingabeaufforderung.

  3. Wählen Sie Als Administrator ausführen.

  4. Wechseln Sie in das Verzeichnis des Message Queue 4.2-Installationsimage.

  5. Führen Sie installer.vbs aus.

• Wenn sich das Deinstallation im Testlaufmodus (uninstaller -n) befindet, führt es fälschlicherweise eine Deinstallation durch. (Fehler 6719051)

  Umgehung: Führen Sie eine automatische Installation mit folgendem Befehl durch:

  uninstaller -s

• Die Zeichenfolge “Install Home” auf der Startseite des Installationsprogramms ist nicht lokalisiert (Fehler 6592491)

Installation unter Solaris

• Wenn das Installationsprogramm im Testlaufmodus (installer –n ) ausgeführt wird, werden auf der Zusammenfassungsseite mehrere Fehlermeldungen angezeigt, und dass der Installationsstatus nicht abgeschlossen wurde. Dies ist falsch und irreführend. Bei einem Testlauf werden keine Komponenten auf dem System installiert, es wird lediglich die Antwortdatei erstellt, die anschließend für die automatische Installation verwendet werden kann. (Fehler 6594351)

• Das Installationsprogramm führt keine Sun Connection-Registrierung durch, wenn die Ausführung im automatischen Modus mit einer Antwortdatei (installer -a filename -s) erfolgt. (Fehler 6710268)

• Wenn das Installationsprogramm im Textmodus ausgeführt wird, kann bei der Eingabe von Benutzernamen oder Passwort für die Sun Connect-Registrierung oder zur Erstellung eines Online-Kontos der Benutzername bzw. das Kennwort nicht mit der Rücktaste korrigiert werden. (Fehler 6673460)

  Workaround: Verwenden Sie statt der Rücktaste die Tastenkombination Strg-H, oder verwenden Sie einen anderen Terminal-Emulator wie dtterm oder xterm.

• Der Upgrade-Bildschirm des Installationsprogramms gibt nicht immer die bestehende installierte Version von Message Queue oder des Installationsmoduls korrekt an. (Fehler 6679765)

• Bei Verwendung des Installationsprogramms im Textmodus und dem Versuch, die Sun Connection-Registrierung mit ungültigem Benutzernamen und Passwort durchzuführen, zeigt das Installationsprogramm ein Dialogfeld an, das besagt, dass die Registrierung nicht möglich ist, gibt eine NULL-Zeiger-Ausnahme aus, und wird beendet. (Fehler 6666365)

Installation unter Linux

Die folgenden Probleme betreffen die Installation auf einer Linux-Plattform.

• Auf dem Bildschirm zur JDK-Auswahl wird in der Scroll-Liste nur ein Element angezeigt. Dies macht es schwierig, weitere JDK in der Liste auszuwählen. (Fehler 6584735)

• Wenn das JDK aktuell ist, und der Benutzer auf der Seite für die JDK-Auswahl die Option zum Installieren des Standard-JDK wählt, fährt das Installationsprogramm mit den Installationsversuchen fort und gibt anschließend die Meldung aus, dass das Paket nicht installiert werden kann. Die Installation wird trotz dieses Problems erfolgreich abgeschlossen. (Fehler 6581310)

• Wenn das aktuell installierte JDK eine spätere Version aufweist als JDK 1.5.0_15 (die normalerweise vom Message Queue-Installationsprogramm installierte Version), kann das Message Queue-Deinstallationsprogramm das standardmäßige IMQ_JAVAHOME-Verzeichnis nicht finden und gibt einen Fehler zurück. (Fehler 6673415)

  Umgehung: Installieren Sie JDK 1.5 wie folgt manuell, bevor Sie das Message Queue-Deinstallationsprogramm ausführen.

  # cd installImage/Product/UNIX/LINUX/X86/2.4/Packages

  # rpm -i --force jdk-1.5.0_15–linux- arch.rpm

  Dabei ist arch entweder i586 oder amd64.

• Wenn das Installationsprogramm im Testlaufmodus (installer –n ) ausgeführt wird, werden auf der Zusammenfassungsseite mehrere Fehlermeldungen angezeigt, und der Installationsstatus wird als nicht abgeschlossen angegeben. Dies ist falsch und irreführend. Bei einem Testlauf werden keine Komponenten auf dem System installiert, es wird lediglich die Antwortdatei erstellt, die anschließend für die automatische Installation verwendet werden kann. (Fehler 6594351)

Installation auf allen Plattformen

Diese Probleme betreffen die Installation auf allen Plattformen.

• Im Bildschirm für die Installationsbereitschaft wird der Produktname als “mq” und nicht als Sun Java System Message Queue 4.2 angezeigt. (Fehler 6650841)

• Solange das Installationsprogramm die Installation von Message Queue 4.2 ausführt und die Seite mit der Fortschrittsanzeige angezeigt wird, ist die Schaltfläche "Abbrechen" aktiv. Das Klicken auf die Schaltfläche "Abbrechen" führt zu einer unvollständigen oder abgebrochenen Installation. (Fehler 6595578)

• Auf der Installationsübersichtsseite werden mehrere Verknüpfungen angezeigt, über die per Mausklick ein Viewer für Protokolle oder Übersichtsseiten angezeigt werden kann. Wenn Sie dieses Viewer-Fenster über die Schaltfläche "X" anstatt über die Schaltfläche "Schließen" schließen, kann dieses Viewer-Fenster nicht erneut geöffnet werden. (Fehler 6587138)

  Umgehung: Verwenden Sie die Schaltfläche "Schließen", um das Fenster zu schließen.

• Wenn sich auf einem Computersystem ältere Versionen von Message Queue und NSS/NSPR befinden, listet der Upgrade-Bildschirm des Installationsprogramm nur Message Queue als Element auf, für das ein Upgrade erforderlich ist. Es wird nicht darauf hingewiesen, dass auch NSS und NSPR aufgerüstet werden müssen. Es werden dennoch alle relevanten Softwarekomponenten aufgerüstet (wie im Bildschirm ReadyToInstall angegeben, der die richtigen Informationen anzeigt). (Fehler 6580696)

• Liste der JDKs im JDK-Auswahlbildschirm ist aktiv, selbst wenn die Option zur Auswahl eines JDK nicht ausgewählt wurde. (Fehler 6650874)

Versionsanomalien im Installationsprogramm

Die Anzeige der Message Queue-Versionsinformationen im Installationsprogramm ist nicht transparent. (Fehler 6586507)

Bei der Solaris-Plattform können Sie aus der folgenden Tabelle die vom Installationsprogramm angezeigte Message Queue-Version bestimmen.

Für Patch-Versionen für 3.6 SP4 (z. B. 3.6 SP4 Patch 1) werden im Installationsprogramm dieselben Zeichenfolgen für die Versionen angezeigt. Sie müssen den Befehl imqbrokerd -version ausführen, um die genaue Version zu bestimmen.

Unter der Linux-Plattform weist die vom Installationsprogramm angezeigte Versionsnummer folgendes Format auf.

Hauptversionsnummer.Unterversionsnummer-bedeutungsloseZahl

Zum Beispiel könnte sie 3.7–22 lauten. Dies gibt lediglich an, dass es sich um eine der 3.7-Versionen handelt, jedoch nicht, um welche genau. Zur Ermittlung der installierten Message Queue-Version müssen Sie folgenden Befehl ausführen:

imqbrokerd -version.

Lokalisierungsprobleme

Die folgenden Probleme beziehen sich auf die Lokalisierung.

• Wenn das Installationsprogramm im Textmodus ausgeführt wird (installer –t ), werden bei anderen Gebietsschemata als Englisch Multibyte-Zeichen unleserlich angezeigt. (Fehler 6586923)

• Auf der Seite mit dem Installationsfortschritt zeigt der Fortschrittbalken merkwürdige Zeichen an. Die QuickInfo bei anderen Gebietsschemata als Englisch ist hartcodiert. (Fehler 6591632)

• Der Textmodus (installer –t) wird unter Windows nicht unterstützt. Beim Ausführen des Installationsprogramms im Textmodus unter Windows wird eine Fehlermeldung angezeigt. Diese Meldung ist nicht lokalisiert, wenn das Installationsprogramm mit einem anderen Gebietsschema als Englisch ausgeführt wird. (Fehler 6594142)

• Auf der Lizenzvereinbarungsseite des Installationsprogramms wird die Lizenzvereinbarung auf Englisch angezeigt, unabhängig davon, mit welchem Gebietsschema das Installationsprogramm ausgeführt wird. (Fehler 6592399)

  Umgehung: Informationen für den Zugriff auf die lokalisierten Lizenzdateien finden Sie in der Datei LICENSE_MULTILANGUAGE.pdf.

• Der Hilfetext zur Verwendung des Installationsprogramms ist nicht lokalisiert. (Fehler 6592493)

• Die Zeichenfolge "None" auf der HTML-Zusammenfassungsseite des Installationsprogramms ist in englischer Sprache hartcodiert. (Fehler 6593089)

• Wenn das Installationsprogramm mit dem deutschen Gebietsschema ausgeführt wird, wird auf der Begrüßungsseite nicht der vollständige Text wie bei anderen Gebietsschemata angezeigt. (Fehler 6592666)

• Die Zeichenfolge "Install Home" ist auf der entsprechenden Seite im Installationsprogramm nicht lokalisiert. Sie wird selbst dann auf Englisch angezeigt, wenn das Installationsprogramm mit einem anderen als dem englischen Gebietsschema ausgeführt wird. (Fehler 6592491)

• Wenn das Installationsprogramm im Textmodus ausgeführt wird (installer –t ), lautet die englischen Antwortauswahl "Yes" und "No", unabhängig von dem Gebietsschema, in dem das Installationsprogramm ausgeführt wird. (Fehler 6593230)

• Auf der Installationsprogrammseite für die JDK-Auswahl ist die QuickInfo für die Schaltfläche zum Durchsuchen in der englischen Version hartcodiert. (Fehler 6593085)

Veraltete Passwortoption

In Vorgängerversionen von Message Queue konnten Sie die —p- oder —password-Option verwenden, um ein Passwort für die folgenden Befehle interaktiv anzugeben: imqcmd, imqbrokerd und imdbmgr. Mit Version 4.0 wurden diese Optionen verworfen.

Stattdessen können Sie eine Passwortdatei erstellen, die die relevanten Passwörter angibt, und mit der Befehlsoption -passfile auf die Passwortdatei verweisen oder einfach ein Passwort eingeben, wenn Sie von dem Befehl dazu aufgefordert werden.

Eine Passwortdatei kann mindestens eins der im Folgenden aufgelisteten Passwörter enthalten.

• Ein Schlüsselspeicherpasswort zum Öffnen des SSL-Schlüsselspeichers. Legen Sie dieses Passwort über die Eigenschaft imq.keystore.password fest.

• Ein LDAP-Repository-Passwort für die sichere Verbindung mit einem LDAP-Verzeichnis, wenn die Verbindung nicht anonym ist. Legen Sie dieses Passwort über die Eigenschaft imq.user_repository.ldap.password fest.

• Ein JDBC-Datenbankpasswort für die Verbindung zu einer JDBC-kompatiblen Datenbank. Legen Sie dieses Passwort über die Eigenschaft imq.persist.jdbc.vendorName.password fest. Die vendorName-Komponente des Eigenschaftsnamen ist eine Variable, die den Datenbankanbieter angibt. Zur Auswahl stehen hadb, derby, pointbase, oracle oder mysql.

• Ein Passwort für den imqcmd-Befehl (zum Ausführen von Broker-Administrationsaufgaben). Legen Sie dieses Passwort über die Eigenschaft imq.imqcmd.password fest.

Im folgenden Beispiel ist in der Passwortdatei als Passwort für die JDBC-Datenbank abracadabra festgelegt.

imq.persist.jdbc.mysql.password=abracadabra

Passwortdateien können auf folgende Weisen verwendet werden:

• Konfigurieren Sie den Broker zur Verwendung der Passwortdatei, indem Sie folgende Eigenschaften in der Datei config.properties des Brokers festlegen.

  imq.passfile.enabled=true

  imq.passfile.dirpath=Passwortdateiverzeichnis

  imq.passfile.name=Passwortdateiname

• Verwenden Sie die Option -passfile des relevanten Befehls, beispielsweise:

  imqbrokerd -passfile Passwortdateiname

Administration/Konfiguration

Die folgenden Probleme beziehen sich auf die Administration und Konfiguration von Message Queue.

• Bei Windows-Plattformen muss die integrierte Windows-Firewall, die standardmäßig aktiviert ist, mit einer Fierwall-Regel dahingehend manuell konfiguriert werden, dass der Broker eingehende Verbindungen von Clients akzeptiert. (Fehler 6675595)

  1. Doppelklicken Sie in der Systemsteuerung auf die Windows-Firewall

     Sie müssen im Dialogfeld für die Benutzerkontensteuerung auf Fortsetzen klicken, um das Einstellungsdialogfeld der Windows-Firewall zu öffnen.

  2. Klicken Sie im Einstellungsdialogfeld der Windows-Firewal auf die Registerkarte Ausnahmen.

  3. Klicken Sie auf Programm hinzufügen.

  4. Wählen Sie im Dialogfeld Programm hinzufügen den Eintrag java.exe aus und klicken Sie auf Durchsuchen.

     Windows identifiziert den Broker-Prozess als Java Platform SE-Binärdatei. Suchen Sie daher die Datei java.exe, die vom Broker verwendet wird (normalerweise unter jdk1.5.0_15\jre\bin\java.exe).

  5. Klicken Sie auf Bereich ändern.

  6. Wählen Sie im Dialogfeld Bereich ändern folgende Option aus: “Alle Computer (einschließlich der im Internet).”

  7. Klicken Sie auf OK .

  8. Klicken Sie im Dialogfeld Programm hinzufügen auf OK.

  9. Klicken Sie im Einstellungsdialogfeld der Windows-Firewall auf OK.

• Auf Windows-Plattformen lösen die Befehle imqadmin and imqobjmgr einen Fehler aus, wenn der CLASSPATH doppelte Anführungszeichen enthält. (Fehler 5060769)

  Umgehung: Öffnen Sie ein Fenster mit einer Eingabeaufforderung und heben Sie die Festlegung von CLASSPATH auf:

  set classpath=

  Führen Sie anschließend den gewünschten Befehl im selben Eingabeaufforderungsfenster aus, beispielsweise:

  mqInstallHome\mq\bin\imqadmin

• Die Option -javahome in Solaris- und Windows-Skripts (alle Versionen) funktioniert nicht, wenn der bereitgestellte Wert ein Leerzeichen enthält. ( Fehler 4683029)

  Die Option javahome wird von den Message Queue-Befehlen und -Programmen verwendet, um eine alternative Java 2-kompatible Runtime anzugeben. Der Pfadname zur alternativen Java-Runtime darf jedoch keine Leerzeichen enthalten. Nachfolgend werden einige Beispiele für Pfade mit Leerzeichen genannt:

  Windows: C:/jdk 1.4

  Solaris: /work/java 1.4

  Umgehung: Installieren Sie die Java Runtime an einem Speicherort oder unter einem Pfad, der keine Leerzeichen enthält.

• Das Attribut imqQueueBrowserMaxMessagesPerRetrieve legt die maximale Anzahl an Nachrichten fest, die von der Client-Runtime in einem Schritt abgerufen werden können, wenn die Inhalte eines Warteschlangenziels durchsucht werden. Das Attribut beeinflusst, wie die Nachrichten in der Warteschlange gestapelt werden, um an die Client-Laufzeit zugestellt zu werden, es hat jedoch keine Auswirkungen auf die Gesamtzahl der durchsuchten Nachrichten. Das Attribut beeinflusst nur den Durchsuchungsmechanismus, nicht die Nachrichtenzustellung. (Fehler 6387631)

Broker-Probleme

Die nachfolgend beschriebenen Probleme beziehen sich auf den Message Queue-Broker.

• Wenn der persistente Datenspeicher zu viele Zielstandorte öffnet, kann auf den Broker nicht mehr zugegriffen werden. (Fehler 4953354)

  Umgehung: Diese Bedingung wird vom Broker verursacht, der das Deskriptor-Limit für die offenen Dateien im System erreicht. Unter Solaris und Linux erhöhen Sie das Dateideskriptor-Limit mit dem Befehl ulimit.

• Konsumenten verwaisen, wenn ein Zielstandort vernichtet wird. ( Fehler 5060787)

  Aktive Konsumenten verwaisen, wenn ein Zielstandort gelöscht wird. Ein verwaister Konsument erhält keine Meldungen mehr (auch dann nicht, wenn der Zielstandort neu erstellt wird).

• Wird ein JMS-Client bei Verwendung des HTTP-Verbindungsdiensts plötzlich beendet (z. B. über Strg-C), benötigt der Broker etwa eine Minute, bevor die Clientverbindung und alle damit zusammenhängenden Ressourcen freigegeben werden.

  Wird innerhalb dieses Zeitraums eine weitere Instanz des Clients gestartet, die versucht, dieselbe Client-ID, Warteschlange oder dasselbe dauerhafte Abonnement zu verwenden, wird möglicherweise ein Ausnahmefehler "Client-ID wird bereits verwendet" ausgegeben. Dies stellt jedoch kein Problem dar, es handelt sich lediglich um eine Nebenwirkung des vorangehend beschriebenen Beendigungsvorgangs. Wenn der Client nach etwa einer Minute gestartet wird, sollte kein Fehler gemeldet werden.

• Bei Verwendung der MySQL-Datenbank für einen Datenspeicher wird bei der Speicherung von Nachrichten mit mehr als 1 MB die Fehlermeldung ausgegeben, dass das Paket für die Abfrage zu groß ist (SQLException). (Fehler 6682815)

  Umgehung: Starten sie den MySQL-Server mit der Option --max_allowed_packet von mehr als dem Standardwert 1 MB. Verwenden Sie beispielsweise folgenden Wert:

  --max_allowed_packet=60M

• Bei Verwendung der Java DB-Datenbank für einen Datenspeicher wird beim Speichern einer Nachricht die Fehlermeldung ausgegeben, dass innerhalb der angeforderten Zeit keine Sperre bezogen werden konnte (SQLException). (Fehler 6691394)

  Umgehung: Fügen Sie den folgenden Eigenschaftswert zur config.properties-Datei des Brokers hinzu.:

  imq.persist.jdbc.derby.table.MYCONSTATE41.index.IDX2=CREATE INDEX &(index) ON $(name) (MESSAAGE_ID)

• Bei Verwendung der MySQL-Datenbank für einen hochverfügbaren gemeinsam genutzten Datenspeicher wird ein Mechanismus benötigt, um das MySQL-Speichermodul als NDBCLUSTER zu konfigurieren. (Fehler 6691394)

  Umgehung: Fügen Sie den folgenden Eigenschaftswert zur config.properties-Datei des Brokers hinzu.:

  imq.persist.jdbc.mysql.tableoption=EMGINE=NDBCLUSTER

Broker-Cluster

Folgende Probleme betreffen Broker-Cluster.

• In dieser Version werden lediglich vollständig verbundene Broker-Cluster unterstützt. Dies bedeutet, dass jeder Broker in einem Cluster direkt mit allen anderen Brokern im Cluster kommunizieren muss. Wenn Sie Broker mithilfe des Befehlszeilenarguments imqbrokerd -cluster zu einem konventionellen Cluster verbinden, müssen Sie darauf achten, dass alle Broker im Cluster enthalten sind.

• Wenn ein Client mit einem Broker in einem Hochverfügbarkeits-Broker-Cluster verbunden ist, versucht die Client-Laufzeit solange, eine Verbindung herzustellen, bis sie erfolg hat (der Wert im Verbindungsfactory-Attribut imqAddressListIterations wird ignoriert.)

• Ein Client kann nur die Inhalte von Warteschlangen durchsuchen, die sich auf seinem Home-Broker befinden. Der Client kann weiterhin Meldungen an eine beliebige Warteschlangesenden und Meldungen von jeder beliebigen Warteschlange im Cluster konsumieren. Die Einschränkung betrifft nur das Durchsuchen der Warteschlange.

• In einem konventionellen Cluster , die Broker mit Version 4.2 enthält, müssen alle Broker Version 3.5 oder höher aufweisen.

• Message Queue 4.2- und 4.1-Broker können standardmäßig nicht in einem Cluster mit Message Queue 3.7- oder 3.6-Brokern interagieren, da sich der Standardwert von imq.autocreate.queue.maxNumActiveConsumers zwischen diesen Versionen geändert hat. (Fehler 6716400)

  UmgehungÄndern Sie bei den Message Queue 4.2- und 4.1-Brokern imq.autocreate.queue.maxNumActiveConsumers vom Standwertwert -1 auf den Standardwert der vorherigen Version, 1.

• Bei der Konvertierung aus einem konventionellen Cluster in einen Hochverfügbarkeits-Cluster können Sie mit dem Datenbank-Manager-Dienstprogramm von Message Queue (imqdbmgr ) einen bestehenden eigenständigen JDBC—basierten Datenspeicher in einen gemeinsam genutzten Hochverfügbarkeits-Datenspeicher konvertieren, wie in Converting a Standalone Data Store to a Shared Data Store in Sun Java System Message Queue 4.2 Administration Guide dokumentiert.

• Ein Broker kann bei Verwendung von HADB ausschließlich Nachrichten bis zu einer Größe von 10 MB verarbeiten. (Fehler 6531734)

• Die Umwandlung in einen HADB-Speicher mit dem Befehl imqdbmgr upgrade hastore kann mit der Fehlermeldung "zu viele Sperren gesetzt" fehlschlagen, wenn der Speicher mehr als 10.000 Nachrichten enthält. (Fehler 6588856)

  Umgehung: Verwenden Sie den folgenden Befehl, um die Anzahl an Sperren zu erhöhen.

  hadbm set NumberOfLocks=<gewünschte_Anzahl>

  Weitere Informationen finden Sie unter "HADB Problems" im Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.

• Wenn mehr als 500 Remote-Nachrichten in einer Transaktion übermittelt werden, gibt der Broker möglicherweise den Fehler "HADB-E-12815: Kein Tabellen-Arbeitsspeicher mehr verfügbar.” (Fehler 6550483)

  Weitere Informationen finden Sie unter "HADB Problems" im Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.

• In einem Broker-Cluster werden die Meldungen an eine entfernte Verbindung, die noch nicht gestartet wurde, in die Warteschlange gestellt. (Fehler 4951010)

  Umgehung: Der Konsument erhält die Meldungen, sobald die Verbindung gestartet wurde. Die Nachrichten werden an einen anderen Konsument gesendet, wenn die Verbindung beendet wird.

• Wenn ein Konsument mehr als eine Nachricht von einem Remote-Broker in einer Transaktion empfängt, ist es möglich, dass die folgende Fehlermeldung für den Broker protokolliert wird. Diese Fehlermeldung ist nicht kritisch und kann ignoriert werden:

  [26/Jul/2007:13:18:27 PDT] WARNING [B2117]: 
  Nachrichtenbestätigung fehlgeschlagen aus
  mq://129.145.130.95:7677/?instName=a&brokerSessionUID=3209681167602264320:
      ackStatus = NOT_FOUND(404)\
      Ursache = Aktualisieren von Remote-Transaktionsstatus auf COMMITED(6): 
  Transaktion 3534784765719091968 nicht gefunden, die Transaktion
  wurde möglicherweise bereits übermittelt.
      AckType = MSG_CONSUMED
      MessageBrokerSession = 3209681167602264320
      TransactionID = 3534784765719091968
          SysMessageID = 8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690
          ConsumerUID = 3534784765719133952\par
  
  [26/Jul/2007:13:18:27 PDT] WARNING Benachrichtigung zur Übermittlung von Transaktion 
  [8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690, 
  [consumer:3534784765719133952, type=NONE]]
  TUID=3534784765719091968 erhielt Antwort: 
  com.sun.messaging.jmq.jmsserver.util.BrokerException:
   Aktualisieren von Remote-Transaktionsstatus auf COMMITED(6): 
    Transaktion 3534784765719091968 nicht gefunden, die Transaktion wurde möglicherweise
    bereits übermittelt:
  com.sun.messaging.jmq.jmsserver.util.BrokerException: Aktualisieren von Remote-Transaktionsstatus 
  auf COMMITED(6): Transaktion 3534784765719091968 nicht gefunden, die Transaktion wurde möglicherweise
   bereits übermittelt.

  Diese Meldung wird im Protokoll erfasst, wenn der Nachrichten-Startbroker für spätere Nachrichten in der Transaktion über die Übermittlung benachrichtigt wurde, sobald die imq.txn.reapLimit-Eigenschaft im Vergleich zur Anzahl an Remote-Nachrichten in einer Transaktion gering ist. (Fehler 6585449)

  Umgehung: Um diese Meldung zu verhindern, erhöhen Sie den Wert der Eigenschaft imq.txn.reapLimit.

JMX-Probleme

Auf der Windows-Plattform gibt die getTransactionInfo-Methode der Überwachungs-MBean für den Transaktionsmanager Transaktionsinformationen zurück, die eine falsche Transaktionserstellungszeit enthalten. (Fehler 6393359)

Umgehung: Verwenden Sie stattdessen die getTransactionInfoByID-Methode der Überwachungs-MBean für den Transaktionsmanager.

SOAP-Unterstützung

Sie sollten zwei Probleme in Verbindung mit der SOAP-Unterstützung beachten.

• Seit der Veröffentlichung von Message Queue Version 4.0 werden SOAP-verwaltete Objekte nicht mehr unterstützt.

• Die SOAP-Entwicklung hängt von mehreren Dateien ab: SUNWjaf, SUNWjmail, SUNWxsrt und SUNWjaxp. In Message Queue Version 4.1 sind diese Dateien nur verfügbar, wenn Sie Message Queue mit JDK Version 1.6.0 oder höher ausführen.

• Bisher verwies die SAAJ 1.2-Implementierungs-Datei .jar direkt auf mail.jar. In SAAJ 1.3 wurde dieser Verweis gelöscht, daher muss sich die Datei mail.jar in Message Queue-Clients ausdrücklich in CLASSPATH befinden.

Dateien für Neuverteilung

Sun Java System Message Queue 4.2 enthält die folgenden Dateisätze, die Sie verwenden und im Binärformat verteilen können:

Außerdem können Sie die Dateien LICENSE und COPYRIGHT ebenfalls neu verteilen.

Eingabehilfen für Personen mit Behinderungen

Um Eingabehilfen zu erhalten, die seit der Veröffentlichung dieses Dokuments auf den Markt gekommen sind, lesen Sie Abschnitt 508 der Produktbewertungen (bei Sun auf Anfrage erhältlich), um die für Sie geeignete Version zu ermitteln. Aktualisierte Anwendungsversionen finden Sie unter: http://sun.com/software/javaenterprisesystem/get.html.

Informationen zum Einsatz von Sun für Eingabehilfen erhalten Sie unter http://sun.com/access.

Problemmeldungen und Feedback

Wenn Sie mit Sun Java System Message Queue Probleme haben, wenden Sie sich an die Kundenunterstützung von Sun. Dazu stehen Ihnen folgende Möglichkeiten zur Verfügung:

• Online-Softwaresupport von Sun unter http://www.sun.com/service/sunone/software.

  Diese Site bietet neben Links zur Knowledge Base, zum Online Support Center und zum ProductTracker auch Wartungsprogramme und Support-Kontaktnummern.

• Wenden Sie sich per Telefon an Sun. Verwenden Sie hierzu die auf Ihrem Wartungsvertrag angegebene Telefonnummer.

Damit wir Sie bestmöglich bei der Problembeseitigung unterstützen können, sollten Sie folgende Informationen zur Hand haben, wenn Sie unser Support-Team kontaktieren:

• Beschreibung des Problems, einschließlich der Situation, in der das Problem auftrat, sowie seine Auswirkungen auf Ihre Arbeit.

• Computertyp, Betriebssystem- und Produktversion, u. a. Patches und andere Softwareanwendungen, die das Problem verursacht haben könnten.

• Detaillierte Schritte zu den von Ihnen verwendeten Methoden, um das Problem zu reproduzieren.

• Sämtliche Fehlerprotokolle oder Kernspeicherauszüge.

Sun Java System-Software-Forum

Unter der folgenden Adresse steht ein Sun Java System Message Queue-Forum zur Verfügung:

http://swforum.sun.com/jive/forum.jspa?forumID=24

Wir freuen uns über Ihre Teilnahme.

Java Technology Forum

Im Java Technology Forum finden Sie möglicherweise ein für Sie interessantes JMS-Forum.

http://forum.java.sun.com

Ihre Meinung ist gefragt

Sun bem�ht sich um eine stetige Verbesserung der Dokumentationen und ist deshalb an Ihrer Meinung und Ihren Anregungen interessiert.

Wenn Sie Kommentare abgeben möchten, rufen Sie die Seite http://docs.sun.com und klicken Sie auf "Kommentare senden". Geben Sie auf dem Onlineformular den Namen und die Bestellnummer der Dokumentation an. Die Teilenummer ist eine sieben- bis neunstellige Zahl, die auf der Titelseite der Buches oder oben auf der Dokumentation angegeben ist. Der Titel des vorliegenden Buches lautet beispielsweise Versionshinweise zu Sun Java System Message Queue 4.2, die Teilenummer lautet 820-3701.

Weitere Quellen von Sun

Nützliche Informationen über Sun Java System finden Sie unter den folgenden Internetadressen:

• Dokumentation

  http://docs.sun.com/prod/java.sys

• Profi-Services

  http://www.sun.com/service/sunps/sunone

• Softwareprodukte und Services

  http://www.sun.com/software

• Softwaresupport

  http://www.sun.com/service/sunone/software

• Support und Knowledge Base

  http://www.sun.com/service/support/software

• Support und Schulung

  http://training.sun.com

• Beratung und Profi-Services

  http://www.sun.com/service/sunps/sunone

• Informationen für Entwickler

  http://developers.sun.com

• Sun-Entwicklersupport

  http://www.sun.com/developers/support

• Softwareschulungen

  http://www.sun.com/software/training