Sun ONE Message Queue 3.0.1 SP2 Versionshinweise

Sun™ ONE Message Queue, Versionshinweise

Version 3.0.1 SP2

Teilenummer 817-3824-10

August 2003

In diesen Versionshinweisen sind wichtige Informationen enthalten, die zum Zeitpunkt der Herausgabe der Version 3.0.1 Service Pack 2 (SP2) von Sun™ Open Net Environment (Sun ONE) Message Queue (MQ) zur Verfügung standen. Hier werden neue Funktionen, Verbesserungen, bekannte Einschränkungen und Probleme, technische Hinweise und andere Informationen behandelt. Lesen Sie dieses Dokument vollständig durch, bevor Sie mit MQ 3.0.1 SP2 arbeiten.

Die neueste Ausgabe dieser Versionshinweise finden Sie auf der Sun ONE-Website für Dokumentationen unter http://docs.sun.com/?p=/coll/S1_MessageQueue_301. Besuchen Sie diese Website vor der Installation und Konfiguration Ihrer Software und später regelmäßig, um stets die neuesten Versionshinweise und Handbücher verfügbar zu haben.

Diese Versionshinweise sind in die folgenden Abschnitte aufgegliedert:

Revisionsverlauf

Tabelle 1  Revisionsverlauf 

Datum

Beschreibung der Änderungen

August 2003

Die folgenden Änderungen wurden an diesem Dokument vorgenommen:

Oktober 2002

Erste Ausgabe dieses Dokuments

Einhaltung von Java™ Message Service (JMS)

MQ 3.0.1-Versionen wurden für die Einhaltung der Java Message Service (JMS) 1.1-Spezifikation zertifiziert und haben die JMS 1.1 Compatibility Test Suite (CTS) bestanden.

MQ 3.0.1 ist der eigentliche JMS-Provider für Sun ONE Application Server 7 und hat ebenfalls den J2EE 1.3.1 CTS-Test von Sun ONE Application Server 7 bestanden (der die Einhaltung von JMS 1.0.2b erfordert).

Neuheiten in Message Queue 3.0.1 SP2

MQ 3.0.1 SP2 ist eine Aktualisierung von MQ 3.0.1 SP1 (bei SP1 handelte es sich um eine Version zur Fehlerbehebung ohne neue Funktionen). MQ 3.0.1 SP1 ist eine Aktualisierung von MQ 3.0.1. In diesen Versionshinweisen beziehen sich Verweise auf 3.0.1-Versionen in der Regel auf 3.0.1, 3.0.1 SP1 bzw. 3.0.1 SP2.

Das Produkt MQ 3.0.1 SP2 enthält alle neuen Funktionen aus MQ 3.0 und 3.0.1 sowie zwei zusätzliche Funktionen aus 3.0.1 SP2.

Neue Funktionen in Message Queue 3.0.1 SP2

MQ 3.0.1 SP2 enthält im Vergleich zu MQ 3.0.1 zwei neue Funktionen:

Neue Funktionen in Message Queue 3.0.1

MQ 3.0.1 enthält im Vergleich zu MQ 3.0 zwei neue Funktionen:

Neue Funktionen in Message Queue 3.0

MQ 3.0 enthält eine Reihe von Änderungen an Version 2.0 des Produkts - iMQ 2.0 (und iMQ 2.0, Service Pack 1).

Eine Besonderheit bei diesen Änderungen ist, dass das Produkt nun in zwei Versionen verfügbar ist - als Platform Edition und Enterprise Edition.

Platform Edition     Stellt grundlegende JMS-Unterstützung zur Verfügung und ist am besten für kleinere Bereitstellungs- und Entwicklungsumgebungen geeignet.

Enterprise Edition     Bietet HTTP/HTTPS-Unterstützung, verbesserte Skalierbarkeit und Sicherheitsfunktionen und ist am besten für umfassende Bereitstellungen geeignet.

(Weitere Informationen zu diesen Editionen finden Sie im MQ-Administrator’s Guide oder im MQ Developer’s Guide.)

Die nachfolgenden Beschreibungen der Änderungen an MQ 3.0.1 sind in Gruppen zusammengefasst, je nachdem, ob sie auf beide oder nur auf die Enterprise Edition zutreffen.

Enterprise und Platform Edition

Nur Enterprise Edition

Aktualisierung der Message Queue-Dokumentation

Die folgenden MQ 3.0.1- und MQ 3.0.1 SP2-Dokumente wurden von der Produktversion 3.0 ausgehend aktualisiert. Sie finden diese aktualisierten Dokumente auf der Sun ONE-Website für Dokumentationen unter http://docs.sun.com/coll/S1_MessageQueue_301.

Installation Guide

Dem MQ-Installation Guide wurden die Änderungen in MQ 3.0.1 SP2 hinzugefügt (siehe auch "Neue Funktionen in Message Queue 3.0.1 SP2").

Administrator’s Guide

Der MQ-Administrator’s Guide wurde aktualisiert, um die Änderungen in MQ 3.0.1 zu reflektieren (siehe auch "Neue Funktionen in Message Queue 3.0.1").

Developer’s Guide

Der MQ Developer’s Guide wurde aktualisiert, um die Änderungen in MQ 3.0.1 zu reflektieren (siehe auch "Neue Funktionen in Message Queue 3.0.1").

Kompatibilität

MQ 3.0.1-Versionen sind vollständig kompatibel mit MQ 3.0. Beim Aufrüsten von MQ 3.0 auf MQ 3.0.1 sind keine Änderungen an der Brokerkonfiguration, an verwalteten Objekten, an Administrationstools oder an Clientanwendungen erforderlich.

Die MQ 3.0.1-Versionen (in diesem Abschnitt einfach als 3.0.1 bezeichnet) sind in der Regel jedoch nicht kompatibel mit iMQ 2.0. Speziell hierzu bestehen einige Punkte, die Sie beim Aufrüsten von iMQ 2.0 (oder iMQ 2.0 Service Pack 1) auf MQ 3.0.1 beachten müssen:

Broker-Kompatibilität

Ein MQ 3.0.1-Broker kann nicht interaktiv mit einem iMQ 2.0-Broker zusammenarbeiten, da Änderungen an den Broker-Eigenschaften und am Persistenzspeicherschema vorgenommen wurden. Einige iMQ 2.0-Daten sind jedoch mit MQ 3.0.1 kompatibel, wie in Tabelle 2 dargestellt, und können beim Aufrüsten auf MQ 3.0.1 erhalten werden. Beachten Sie beim Aufrüsten von iMQ 2.0 auf MQ 3.0.1 die folgenden Punkte:

Kompatibilität der verwalteten Objekte

MQ Verwaltete 3.0.1-Objekte wurden mit neuen Attributen erweitert und iMQ 2.0-Attribute wurden umbenannt. Beachten Sie daher beim Aufrüsten von iMQ 2.0 auf MQ 3.0.1 die folgenden Punkte:

Kompatibilität des Administrationstools

Da sehr viele Dateien und Verzeichnisse umbenannt wurden (vor allem das Ersetzen der Zeichenfolge "jmq" durch "imq"), müssen in MQ 3.0.1 alle Befehlszeilenprogramme, Broker-Eigenschaften, verwaltete Objektattribute und interne Dateinamen umbenannt werden. Beachten Sie daher beim Aufrüsten von iMQ 2.0 auf MQ 3.0.1 die folgenden Punkte:

Client-Kompatibilität

Beachten Sie beim Aufrüsten von iMQ 2.0 auf MQ 3.0.1 die folgenden Punkte:

Bekannte Einschränkungen

Die in diesem Abschnitt erläuterten Einschränkungen sind in Gruppen zusammengefasst, je nachdem, ob sie auf beide oder nur auf die Enterprise Edition der MQ 3.0.1-Versionen zutreffen.

Enterprise und Platform Edition

Nur Enterprise Edition

Bekannte Fehler

In diesem Abschnitt werden die wichtigsten Fehler beschrieben, die zum Zeitpunkt der Ausgabe von MQ 3.0.1 SP2 bekannt waren.

Für eine Liste der aktuellen Fehler, ihres Status und der Umgehungsmöglichkeiten finden Mitglieder der Java Developer Connection (TM) auf der Bug Parade der Java Developer Connection-Website. Besuchen Sie diese Seite, bevor Sie einen neuen Fehler melden. Auch wenn nicht alle MQ-Fehler aufgelistet sind, ist dies ein guter Ausgangspunkt, wenn Sie feststellen möchten, ob ein Problem bekannt gegeben wurde.

Die Adresse der Seite lautet:

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

Tabelle 3  Fehlerbeschreibung 

Fehlernummer

Details

4431924

imqadmin: Modale Dialogfelder können sich gegenseitig sperren (Deadlock).

Die Administrationskonsole (imqadmin) verwendet anwendungsgebundene Dialogfelder. Die meisten dieser Dialogfelder werden ausdrücklich durch die Interaktion mit der grafischen Benutzeroberfläche aufgerufen, beispielsweise durch die Auswahl des Menüs "Broker hinzufügen". Ein Dialog kann aber auch aufgrund einer getrennten Brokerverbindung angezeigt werden. Ist mehr als ein Dialogfeld geöffnet, wird die Adminstriationskonsole gesperrt. Sie können keines der modalen Dialogfelder mit der Option "Schließen" beenden.

Umgehung: Beenden Sie das oberste Dialogfeld über die Fenstersteuerungen, z. B.

       - über die Schaltfläche "X" oben rechts unter Windows

       - über das Menü "Schließen" unter Solaris

4449354

In ganz seltenen Fällen führt der gleichzeitige Aufruf der Methoden Connection.stop, Connection.start und Connection.close mit den Methoden Session.recover und Session.rollback (in separaten Threads) zu einer unerwarteten Reihenfolge bei der erneuten Sendung von Meldungen.

Umgehung: Stellen Sie sicher, dass Ihre Aufrufe an die oben angegebenen Methoden Connection… und Session… entweder durch die Verwendung desselben Threads oder mithilfe der Synchronisation serialisiert werden.

4683029

Die Option -javahome in allen solaris/win-Skripten funktioniert nicht, wenn der Wert ein Leerzeichen enthält.

Die Option -javahome wird von den MQ-Befehlen und -Programmen verwendet, um eine alternative Java 2-kompatible Runtime anzugeben. Der Pfad zur alternativen Java-Runtime darf jedoch keine Leerzeichen enthalten.

Beispiele für Pfade, die Leerzeichen enthalten:

      Windows:

      C:\jdk 1.4 (Unter Windows kann ein Pfad Leerzeichen enthalten, wenn der gesamte Pfad in Anführungszeichen gesetzt wird, beispielsweise "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.

4689962

In der japanischen Sprache ist die Ausgabe verschiedener Administrationsprogramme nicht ordnungsgemäß in Spalten ausgerichtet und die Rahmen sind zu kurz.

Umgehung: Keine

4703406

QueueBrowser sollte funktionieren, ohne zunächst connection.start() aufrufen zu müssen.

Connection.start() muss auf einer Verbindung aufgerufen werden, bevor QueueBrowser eine Warteschlange durchsuchen kann. Wenn Sie Connection.start() nicht aufrufen, blockiert die QueueBrowser-Aufzählung nextElement() und meldet schließlich eine java.util.NoSuchElementException.

Umgehung: Rufen Sie Connection.start() auf, bevor Sie QueueBrowser.getEnumeration() aufrufen.

4753010

Uneingeschränktes Wachstum im eigentlichen Heap-Segment (Java-Prozess) mit der Server-VM.

Hierbei handelt es sich um einen Java VM-Fehler, der den Broker-Prozess bei schnellem Öffnen und Schließen von Clientverbindungen beeinflussen kann. Dies kann dazu führen, dass der Broker-Prozessspeicher kontinuierlich und uneingeschränkt anwächst. Nachdem der gesamte Systemspeicher verbraucht wurde, stürzt der Broker schließlich ab.

Das Wachstum des eigentlichen Heap-Segments kann mit dem Werkzeug /usr/proc/bin/pmap überprüft werden.

Umgehung: Zwingen Sie den Broker mit dem folgenden Befehl, die Client-VM zu verwenden:

    imqbrokerd -clientvm

Alternativ können Sie das Argument -server im Shell-Skript /usr/bin/imqbrokerd entfernen, das den Broker startet. Oder Sie rüsten auf JDK 1.4.1 und verwenden den folgenden Befehl:

    imqbrokerd -javahome JDK_1.4.1_directory

4761626

Umfangreiche Konsumentenerstellungs- und -löschvorgänge bei automatischer Erstellung von Warteschlangen kann zu Meldungsverlusten führen.

In seltenen Stresssituationen kann eine Meldung aus einem automatisch erstellten Warteschlangenziel verloren gehen.

Dieser Fehler tritt auf, wenn alle aus der Warteschlange gesendeten Nachrichten bestätigt wurden und der letzte Meldungskonsument zur selben Zeit entfernt wird, zu der ein neuer Meldungserzeuger (einer anderen Verbindung) eine Meldung an diese Warteschlange sendet. In diesem Fall wird die Warteschlange genau dann automatisch entfernt (sie ist leer und ohne Konsumenten), wenn die neue Meldung eintrifft, sodass diese verloren geht.

Umgehung: Erstellen Sie Warteschlangen mithilfe der MQ-Administrationstools.

4879448

Sun ONE Message Queue Version 3.0.1 lagert persistente Meldungen nicht auf die Festplatte aus, wenn der Heap den Speicherstatus RED erreicht.

Es gibt einen Boole'schen Ausdruck, der ermittelt, ob die Logik einer Meldung ungültig ist. Ist die Logik ungültig, sollte die Meldung ausgelagert werden. Demzufolge werden in manchen Fällen persistente Meldungen aus dem Speicher ausgelagert. Wird die Funktion zum Auslagern nichtpersistenter Meldungen deaktiviert, werden persistente Meldungen stets richtig ermittelt.

Umgehung: Legen Sie in der Datei config.properties oder über die Befehlszeile die folgenden Broker-Eigenschaften fest:
imqmemory_management.swapNPMsps=false

4883126

Die Funktion zum automatischen Wiederherstellen einer Verbindung arbeitet nicht ordnungsgemäß.

Die Anzahl an Konsumenten wächst nach jedem automatischen Wiederherstellen einer Verbindung an, sodass der Broker Meldungen doppelt sendet.

Umgehung: Keine. Dieser Fehler wird in MQ 3.5 behoben.

4888270

Die erneute Übertragung einer Meldung, die ursprünglich in einer Transaktion gesendet wurde, verursacht einen Broker-Fehler.

  Wird eine ursprünglich in einer Transaktion gesendete Nachricht   anschließend empfangen und dasselbe Meldungsobjekt wird in einer nicht transaktionalen Sitzung erneut übertragen, meldet der Broker einen Fehler.

  Umgehung: Verwenden Sie nicht dasselbe Meldungsobjekt. Wenn Sie die Meldung   wirklich erneut übertragen möchten, erstellen Sie eine neue separate Meldung.

4893546

Der Broker gibt keinen Speicher frei, wenn er mit JDK 1.4.2 und der Server-VM ausgeführt wird.

Umgehung: Verwenden Sie die Client-VM. Der Broker sollte mithilfe des folgenden Befehls gestartet werden:

imqbrokerd -clientvm

In Message Queue 3.0.1-Versionen behobene Fehler

Nachfolgend finden Sie eine kurze Beschreibung der wichtigsten Fehler, die in MQ 3.0.1, 3.0.1 SP1 und 3.0.1 SP2 behoben wurden.

Informationen zu den in MQ 3.0 behobenen Fehlern finden Sie in den Versionshinweisen zu MQ 3.0, die unter folgender Adresse zur Verfügung stehen:

Weitere Einzelheiten zu allen hier beschriebenen behobenen Fehlern finden Sie im vollständigen Bericht zu diesem Thema auf der Java Developer Connection-Website unter

Tabelle 4  In MQ 3.0.1-Versionen behobene Fehler 

Fehlernummer

Beschreibung

4679837

Der Client meldet gelegentlich den Ausnahmefehler JMSException bei connection.close(), wenn für den Transport TLS verwendet wird.

4683129

Der Zeitstempel des Broker-Protokolls wird zwischen Mitternacht und 1 Uhr morgens nicht richtig angegeben.

4688051

Der Client kann den Ausnahmefehler EOFException erhalten, wenn Verbindungen zum Broker schnell geöffnet und geschlossen werden.

4694971

Die Durchführung von unabhängigen JTS/XA-Transaktionen schlägt gelegentlich fehl, auch nach einem normalen, fehlerfreien XAConnection.close().

4700851

Der Client bereinigt lokale Transaktionen nach Beenden einer XA-Transaktion nicht.

4701982

Die Administrationskonsole kann unter Solaris oder Linux nicht gestartet werden, wenn die Umgebungsvariable CLASSPATH festgelegt wurde.

4702152

Der Broker bewahrt für jede im Rahmen einer Konsumententransaktion bestätigte Meldung nutzlose Statusinformationen auf, bis der Konsument geschlossen wird.

4704186

Korrekturen in der README-Datei (demo/jms/README) der Beispielanwendungen.

4735757

Ein Konsument meldet einen Ausnahmefehler, wenn mehr als 50 Meldungen in einer Transaktion empfangen werden, bevor commit() aufgerufen wird.

4758424

Die Leistung wird auf der Round Robin-Warteschlange vermindert, wenn der Meldungsrückstand 10k beträgt.

4758427

Round Robin-Warteschlangekonsumenten können "stecken bleiben", wenn die letzte Meldung in der Warteschlange vor dem Senden verfällt.

4770212

Das Anhalten und Fortsetzen eines Dienstes führt zum Aussetzen von Clientverbindungen, wenn in den Verbindungen keine ausstehenden Meldungen vorhanden sind.

4770518

Der Broker-Dienst für Windows wird beim Abmelden beendet.

4809079

Der Broker wird nicht ordnungsgemäß beendet, wenn SSL-basierte Verbindungen bestehen.

4821708

Session.createProducer(null) meldet Ausnahmefehler NullPointerException.

4828860

Die MQ-Leistung wird auf der Auswahl vermindert und verschlechtert sich weiter bei steigender Anzahl an Clients.

4835586

Der Wiederherstellungszyklus beim Master-Broker-Backup kann den Verlust von Zielinformationen zur Folge haben.

4879448

Unter bestimmten Bedingungen lagert der Broker Meldungen nicht auf die Festplatte aus.

Optionale Funktionen von JMS

Gemäß der JMS-Spezifikation sind einige Funktionen optional. Jeder JMS-Provider (Entwickler) entscheidet, ob diese implementiert werden oder nicht. Verwendung dieser Optionen in MQ wird nachfolgend erläutert.

Tabelle 5  Optionale JMS-Funktionen 

Sektion in der JMS-Spezifikation

Beschreibung und Verwendung in MQ

3.4.3
JMSMessageID

"Da Meldungs-IDs zum Erstellen und Vergrößern einer Meldung Leistung abzweigen, ist es für manche JMS-Provider möglich, den Meldungsaufwand zu optimieren, wenn sie einen Hinweis erhalten, dass die entsprechende Meldungs-ID von einer Anwendung verwendet wird. Der JMS Message Producer stellt einen Hinweis zum Deaktivieren von Meldungs-IDs zur Verfügung."

MQ-Implementierung: Das Produkt deaktiviert die Erzeugung von Meldungs-IDs nicht (alle setDisableMessageID()-Aufrufe in MessageProducer werden ignoriert). Alle Meldungen verfügen über eine gültige Meldungs-ID.

3.4.12
Überschreiben von Meldungs-Header-Feldern

"JMS definiert nicht genau, wie ein Administrator diese Header-Feldwerte überschreibt. Ein JMS-Provider muss diese administrative Option nicht unterstützen."

MQ-Implementierung: Das MQ-Produkt unterstützt das administrative Überschreiben der Werte in den Meldungs-Header-Feldern über die Konfiguration verwalteter Verbindungs-Factory-Objekte.

3.5.9
JMS-definierte Eigenschaften

"JMS reserviert das Eigenschaftennamenpräfix "JMSX" für JMS-definierte Eigenschaften."
"Sofern nicht anders angegeben ist die Unterstützung dieser Eigenschaften optional."

MQ-Implementierung: Die in der JMS 1.1-Spezifikation definierten JMSX-Eigenschaften werden in MQ unterstützt.

3.5.10
Provider-spezifische Eigenschaften

"JMS reserviert das Eigenschaftennamenpräfix "JMS_<entwickler_name>" für Provider-spezifische Eigenschaften."

MQ-Implementierung: Der Zweck der Provider-spezifischen Eigenschaften besteht darin, besondere Funktionen zur Verfügung zu stellen, die für die JMS-Verwendung mit Provider-nativen Clients erforderlich sind. Sie sollten nicht für JMS zum JMS-Messaging verwendet werden. MQ 3.0.1 verwendet Provider-spezifische Eigenschaften nicht.

4.4.8
Verteilte Transaktionen

"JMS erfordert keine Provider-Unterstützung von verteilten Transaktionen."

MQ-Implementierung: Verteilte Transaktionen werden in dieser Version von MQ unterstützt.

4.4.9
Mehrfachsitzungen

"Für PTP <Punkt-zu-Punkt-Verteilungsmodell> gibt JMS keine Semantik für gleichzeitige QueueReceivers in derselben Warteschlange an. JMS untersagt einem Provider die Unterstützung dieser Funktion jedoch nicht." Weitere Informationen hierzu finden Sie im Abschnitt 5.8 der JMS-Spezifikation.

MQ-Implementierung: Die MQ-Implementierung unterstützt drei Warteschlangenzustellungsverfahren: Failover, Round Robin und Einzeln (Standard). Weitere Informationen hierzu finden Sie im MQ-Administrator’s Guide.

Technische Hinweise

In diesem Abschnitt finden Sie jeweils eine kurze Übersicht zu den folgenden Themen:

Systemuhreinstellungen

Bei der Verwendung eines MQ-Systems sollten Sie die Systemuhren sorgfältig synchronisieren und nicht zurückstellen.

Synchronisation empfohlen

Es wird empfohlen, die Uhren auf allen Hosts zu synchronisieren, die mit dem MQ-System interaktiv arbeiten. Dies ist vor allem dann wichtig, wenn Meldungen zu einem bestimmten Zeitpunkt ablaufen (TimeToLive). Werden die Hostuhren nicht sychnronisiert, kann diese Funktion nicht ordnungsgemäß funktionieren (Meldungen werden möglichweise nicht gesendet). Synchronisieren Sie die Uhren, bevor Sie einen Broker starten.

Solaris     Sie können den Befehl rdate auf einem lokalen Host verwenden, um diesen mit einem Remote-Host zu synchronisieren. (Sie müssen als Superuser bzw. Root angemeldet sein, um diesen Befehl ausführen zu können.) Der folgende Befehl synchronisiert beispielsweise den lokalen Host (Host2) mit dem Remote-Host1:

Linux     Der Befehl ist ähnlich wie bei Solaris, es ist jedoch die Option -s erforderlich:

Windows     Sie können den net-Befehl mit dem time-Unterbefehl verwenden, um den lokalen Host mit einem Remote-Host zu synchronisieren. Der folgende Befehl synchronisiert beispielsweise den lokalen Host (Host2) mit dem Remote-Host1:

Systemuhren nicht zurückstellen

Vermeiden Sie das Zurückstellen von Systemuhren auf Systemen, die einen MQ-Broker ausführen. MQ verwendet Zeitstempel, um die Identifikation interner Objekte wie Transaktionen oder dauerhafter Abonnements zu erleichtern. Wird die Systemuhr zurückgestellt, ist es theoretisch möglich, dass eine doppelte interne ID erzeugt wird. Der Broker versucht dies zu kompensieren, indem IDs mehr zufällig verarbeitet werden und indem (solange er ausgeführt wird) Abweichungen von der Uhrzeit ermittelt werden. Wird die Systemuhr jedoch um einen größeren Wert zurückgestellt während kein Broker ausgeführt wird, besteht ein mögliches Risiko einer ID-Duplizierung.

Wenn Sie die Systemuhr auf einem System, das einen Broker ausführt, um mehrere Sekunden zurückstellen müssen, empfiehlt es sich zu warten, bis keine Transaktionen oder dauerhafte Abonnements vorhanden sind oder bis der Broker nicht mehr ausgeführt wird. Warten Sie genau die Zeit ab, um die Sie die Uhr zurückgestellt haben, und starten Sie dann erneut den Broker.

Am besten ist es jedoch, die Uhren zu synchronisieren, bevor Broker gestartet werden. Verwenden Sie dann die passende Methode, um sicherzustellen, dass die Uhren nach der Bereitstellung nicht beträchtlich voneinander abweichen.

Betriebssystembedingte Verbindungseinschränkungen für Clients und Broker

Auf den Solaris- und Linux-Plattformen platziert die Shell, in der der Client oder Broker ausgeführt wird eine weiche Begrenzung auf die Anzahl an Dateibeschreibungen, die ein Client verwenden kann. Im MQ-System wird für jede Verbindung, die ein Client herstellt oder ein Broker akzeptiert, eine dieser Dateibeschreibungen verwendet. Daher kann ein Broker oder Client nicht mit mehr als 256 Verbindungen unter Solaris oder 1024 Verbindungen unter Linux ausgeführt werden, ohne diesen Grenzwert zu ändern. (Diese Zahl fällt tatsächlich etwas niedriger aus, da manche Dateibeschreibungen für andere Zwecke verwendet werden, beispielsweise dateibasierte Persistenz.)

Informationen zum Ändern dieses Grenzwerts finden Sie auf der Man Page ulimit oder in den nachfolgenden Anweisungen unter "Anheben der zulässigen Anzahl an Dateibeschreibungen zum Verbessern der dateibasierten Persistenzleistung". Der Grenzwert muss in jeder Shell geändert werden, in der ein Client oder Broker ausgeführt wird.

Anheben der zulässigen Anzahl an Dateibeschreibungen zum Verbessern der dateibasierten Persistenzleistung

Auf den Solaris- und Linux-Plattformen wird die Geschwindigkeit beim Speichern von Meldungen in der standardmäßigen dateibasierten Persistenz durch die Anzahl an verfügbaren Dateibeschreibungen für die Verwendung durch den Dateispeicher beeinflusst. (Windows verfügt nicht über einen solchen Grenzwert.) Eine große Anzahl an Dateibeschreibungen ermöglicht es dem System, eine große Anzahl an persistenten Meldungen schneller zu verarbeiten.

Zur Leistungssteigerung bei Leistungstests oder bei der Bereitstellung sollten Administratoren die maximale Anzahl an Dateibeschreibungen für eine Anwendung (in diesem Fall der Broker-Prozess) anheben und dann den gemeinsam genutzten Dateibeschreibungspool vergrößern (der vom Broker verwendet wird). Hierfür wird der Wert der folgenden Eigenschaft aktualisiert:

Der Wert dieser Eigenschaft muss unter der maximalen Anzahl an Dateibeschreibungen liegen, die auf Ihrem System verfügbar sind.

Unter Solaris können Sie beispielsweise diese Grenzwerte mit dem Befehl ulimit anheben. Die Prozesse erben Systembegrenzungen von ihrer übergeordneten Shell (Anmeldung). Unter Solaris gibt es eine "harte" und eine "weiche" Begrenzung. Für einen Benutzer, der nicht als Root angemeldet ist, darf die Anzahl an Dateibeschreibungen die weiche Begrenzung nicht überschreiten, die wiederum nicht die harte Begrenzung überschreiten darf.

So stellen Sie die aktuellen Begrenzungen für Dateibeschreibungen fest:

So ändern Sie die Dateibeschreibungsbegrenzungen für einen Root-Benutzer:

Anschließen kann jeder in dieser Shell erstellte Prozess eine unbegrenzte Anzahl an Dateibeschreibungen öffnen. Daher ist es nun unbedenklich, den Befehl imqbroker auszuführen.

So ändern Sie die Dateibeschreibungsbegrenzungen für einen Standardbenutzer:

wobei nummer1 weniger als 1024 beträgt und nummer2 weniger als nummer1.

Sollte 1024 nicht ausreichen, stehen folgende Optionen zur Verfügung:

Sichern persistenter Daten

Der Broker verwendet einen Persistenzspeicher, der neben anderen Informationen Meldungsdateien enthalten kann, die vorübergehend aufbewahrt werden. Da diese Meldungen proprietäre Informationen enthalten können, empfiehlt es sich, den Datenspeicher gegen unzulässigen Zugriff zu sichern.

Ein Broker kann entweder die integrierte oder die Plug-in-Persistenz verwenden.

Integrierter Persistenzspeicher

Ein Broker, der die integrierte Persistenz verwendet, schreibt persistente Daten in einen Flatfile-Datenspeicher unter

wobei brokerName die Broker-Instanz identifiziert.

Das Verzeichnis brokerName/filestore/ wird erstellt, wenn die Broker-Instanz zum ersten Mal gestartet wird. Die Vorgehensweise zum Sichern dieses Verzeichnisses hängt vom Betriebssystem ab, auf dem der Broker ausgeführt wird.

Solaris und Linux     Die Berechtigungen für das Verzeichnis IMQ_VARHOME/instances/brokerName/filestore/ hängen von den umask-Zugriffsrechten des Benutzers ab, der die Broker-Instanz gestartet hat. Daher kann die Berechtigung zum Starten einer Broker-Instanz und zum Lesen der zugehörigen persistenten Dateien eingeschränkt werden, indem die umask-Zugriffsrechte entsprechend festgelegt werden. Alternativ kann ein Administrator (Superuser) persistente Daten sichern, indem er die Berechtigungen für das Verzeichnis IMQ_VARHOME/instances auf 700 einstellt.

Windows     Die Berechtigungen für das Verzeichnis IMQ_VARHOME/instances/brokerName/filestore/ können mithilfe der vom jeweiligen Windows-Betriebssystem zur Verfügung gestellten Methoden eingestellt werden. Hierbei muss in der Regel ein Eigenschaftendialog für das Verzeichnis geöffnet werden.

Plug-in-Persistenzspeicher

Ein Broker, der Plug-in-Persistenz verwendet, schreibt die persistenten Daten in eine JDBC-kompatible Datenbank.

Für eine von einem Datenbankserver verwaltete Datenbank (z. B. eine Oracle-Datenbank) empfiehlt es sich, für den Zugriff auf die MQ-Datenbanktabellen (Tabellen, deren Namen mit "IMQ" beginnen) einen Benutzernamen und ein Passwort zu erstellen. Wenn es in der Datenbank nicht möglich ist, einzelne Tabellen zu schützen, erstellen Sie eine gesonderte Datenbank, die nur von MQ-Brokern verwendet werden darf. Wenden Sie sich an den Entwickler der Datenbank, um Anleitungen zum Erstellen des Zugriffs über Benutzernamen und Passwort zu erhalten.

Der zum Öffnen einer Datenbankverbindung mit einem Broker erforderliche Benutzername und das entsprechende Kennwort können als Broker-Konfigurationseigenschaften eingerichtet werden. Es ist jedoch sicherer, diese als Befehlszeilenoptionen für den Start des Brokers einzurichten (siehe auch MQ-Administrator’s Guide, Anhang A, "Setting Up Plugged-in Persistence").

Im Falle einer eingebetteten Datenbank, auf die der Broker direkt über den JDBC-Treiber der Datenbank zugreift (z. B. eine Cloudscape-Datenbank), wird die Sicherheit normalerweise über die Einstellung von Dateiberechtigungen auf das Verzeichnis gewährleistet, in dem die persistenten Daten gespeichert werden (wie oben unter "Integrierter Persistenzspeicher," beschrieben). Um sicherzustellen, dass die Datenbank vom Broker und dem Programm imqdbmgr gelesen und bearbeitet werden kann, sollten beide jedoch vom selben Benutzer ausgeführt werden.

Broker-Speicherkonfiguration

Wenn der Broker den von Java-Objekten verwendeten JVM-Heap-Speicher fast verbraucht hat, stehen zum Freigeben von Speicher verschiedene Methoden zur Auswahl, beispielsweise die Flusssteuerung und die Auslagerung von Meldungen. Unter extremen Bedingungen können sogar Clientverbindungen geschlossen werden, um Speicher freizugeben und den Strom eingehender Meldungen zu verringern. Daher ist es sinnvoll, den Maximalwert für den JVM-Heap-Speicher hoch genug einzustellen, um solche Umstände zu vermeiden.

Wird dieser Wert jedoch in Relation zum physikalischen Systemspeicher zu hoch eingestellt, kann der Broker den Java-Heap-Speicher solange füllen, bis der gesamte Systemspeicher erschöpft ist. Dies kann in verminderter Leistung, unvorhergesehenen Broker-Abstürzen resultieren und/oder das Verhalten anderer Anwendungen und Dienste beeinflussen, die auf dem System ausgeführt werden.

Um dieses Problem zu vermeiden, konfigurieren Sie mit dem Java-Befehlszeilenargument -Xmx eine sinnvolle Größenbeschränkung für den Java-Heap. Es ist hilfreich, zunächst die Systemspeicher-Footprints zu normalen und zu Spitzenzeiten zu ermitteln. Konfigurieren Sie dann den Java-Heap so, dass seine Größe gute Leistung bietet, nicht aber das Risiko von Systemspeicherproblemen birgt.

Speicherprobleme bei Clients

Wenn Sie einen JMS-Client ausführen, der große oder viele kleine Meldungen verarbeiten muss, kann es zu OutOfMemoryError-Fehlern kommen. In der Client-Runtime liegt kein Problem mit der Freigabe von Speicher vor. Es ist lediglich nicht ausreichend Speicher vorhanden, um die Meldungen vom Netzwerk zu kopieren und Sie an Ihren Client zu senden.

Um die OutofMemoryError-Fehler zu beseitigen, erhöhen Sie die maximale Größe für den Java-Heap. Übergeben Sie die entsprechende Befehlszeilenoption an den Befehl java oder jre.

Unter Java2 verwenden Sie beim Ausführen der Clientandwendung die Option -Xmx. Zum Beispiel:

Beachten Sie folgende Einschränkungen:

So können Sie Probleme mitteilen

Schreiben Sie eine E-Mail an imq-feedback@sun.com.

Wenn Sie einen Unterstützungsvertrag haben und Probleme mit MQ auftreten, wenden Sie sich an den Kundendienst von Sun ONE. Folgende Möglichkeiten stehen zur Auswahl:

Damit wir Sie optimal beraten können, halten Sie bitte die folgenden Informationen bereit, wenn Sie sich an die Kundenunterstützung wenden:

Weitere Informationen

Zusätzlich zur MQ-Dokumentation finden Sie an den unten angegebenen Orten zusätzliche Informationen.

Diskussionsforen

Sun ONE Software Forum

Unter der nachfolgenden Adresse finden Sie ein Sun ONE MQ-Forum:

Java Technology Forum

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

Kommentare sind willkommen

Sun möchte seine Dokumentation laufend verbessern. Ihre Kommentare und Vorschläge sind daher immer willkommen. Bitte senden Sie Kommentare per E-Mail an folgende Adresse:

Geben Sie die Teilenummer (817-3824-10) des Dokuments in der Betreffzeile an und nennen Sie den Buchtitel (Message Queue 3.0.1 Versionshinweise) im Text Ihrer E-Mail.

Weitere Informationen über Sun

Nützliche Informationen über Sun ONE finden Sie unter den folgenden Internet-Adressen:

Copyright © 2003 Sun Microsystems, Inc. Alle Rechte vorbehalten.

Sun, Sun Microsystems, das Sun-Logo, Solaris, Java, das Java Kaffeetassen-Logo, JDBC und JDBC Compliant sind Marken oder registrierte Marken von Sun Microsystems, Inc. in den USA und anderen Ländern. Die Verwendung von Sun ONE Message Queue unterliegt den in der beiliegenden Lizenzvereinbarung beschriebenen Bedingungen.