In diesem Abschnitt werden die bekannten Probleme mit Message Queue 3.7 UR1 aufgeführt. Dies betrifft die folgenden Produktbereiche:
Eine Liste der aktuellen Fehler, deren Status und Umgehungsmöglichkeiten finden Sie als Mitglied der Java Developer Connectionn™ 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 .
Ein Verbindungsdienst, der SSL verwendet, ist derzeit auf die Unterstützung von selbstsignierten Serverzertifikaten eingeschränkt, d.h. auf den beglaubigten Hostmodus.
Wird ein JMS-Client bei Verwendung des HTTP-Transports 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.
In Message Queue 3.7 UR1 wird die Beispielkonfiguration für einen Broker unter Verwendung eines LDAP-Servers als Benutzer-Repository im Kommentarbereich der Datei config.properties angezeigt. Das Beispiel für das LDAP-Benutzer-Repository in der Datei default.properties ist auskommentiert.
Wenn Sie bisher einen Eigenschaftswert der Beispiel-LDAP-Benutzer-Repository-Eigenschaften in der Datei default.properties verwendet haben, erhält Ihr JMS-Anwendungs-Client einen Sicherheitsausnahmefehler bei dem Versuch, eine JMS-Verbindung herzustellen. Dieses Problem tritt nach einem Upgrade auf Message Queue 3.7 UR1 auf.
Wenn Ihr JMS-Client versucht, eine Verbindung mit dem Message Queue 3.7 UR1-Broker herzustellen, erhalten Sie einen Fehler im Broker-Protokoll und Ihr JMS-Client erhält folgenden Ausnahmefehler:
SecurityException. 20/Aug/2004:11:16:41 PDT] ERROR [B4064]: Ldap repository ldap property .uidattr not defined for authentication type basic:com.sun.messaging.jmq.auth.LoginException: [B4064]: Ldap repository ldap property .uidattr not defined for authentication type basic
Umgehung Setzen Sie die Broker-Eigenschaft imq.user_repository.ldap.uidattr gemäß den Anweisungen in Kapitel 7, Managing Security in Sun Java System Message Queue 3.7 UR1 Administration Guide.
Die folgenden Punkte beziehen sich auf die Verwendung von Broker-Clustern.
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 verbinden, stellen Sie sicher, dass alle Broker im Cluster enthalten sind.
Ein Client, der mit einem Broker verbunden ist, der wiederum Teil eines Clusters ist, kann QueueBrowser nicht zum Durchsuchen von Warteschlangen nutzen, die sich auf Remote-Brokern in diesem Cluster befinden. Der Client kann nur die Warteschlangeninhalte durchsuchen, die sich auf dem Broker befinden, mit dem er direkt verbunden ist. Der Client sendet eventuell noch Meldungen an eine beliebige Warteschlange oder erhält Meldungen von einer Warteschlange oder einem Broker im Cluster. Die Einschränkung betrifft nur das Durchsuchen.
Wird im Broker-Cluster kein Master-Broker verwendet, werden persistente Informationen, die in einem dem Cluster neu hinzugefügten Broker gespeichert sind, nicht an die anderen Broker im Cluster weitergegeben.
Verbindung wird getrennt für einen Broker im Cluster (Fehlernummer 6377527).
Dieser Fehler kann eintreten, wenn die Adresse des Brokers (dessen Verbindung getrennt wird) in die Loopback-IP-Adresse (127.0.0.1) aufgelöst wird.
Umgehung Stellen Sie sicher, dass die Broker-Adresse nicht in die Loopback-IP-Adresse aufgelöst wird.
In einem Broker-Cluster werden die Nachrichten an eine Remoteverbindung, die eventuell noch nicht gestartet wurde, in die Warteschlange gestellt (Fehlernummer 4951010).
UmgehungDer Verbraucher erhält die Nachrichten, sobald die Verbindung gestartet wurde. Die Nachrichten werden an einen anderen Verbraucher gesendet, wenn die Verbindung beendet wird.
Die folgenden Probleme beziehen sich auf die Administration und Konfiguration von Message Queue.
Die Dienstprogramme imqadmin und imqobjmgr geben einen Fehler aus, wenn CLASSPATH auf Windows-Computern doppelte Anführungszeichen enthält (Fehlernummer 5060769)
Umgehung Sie können diese Fehlermeldung ignorieren. Der Broker informiert die Verbraucher ordnungsgemäß über mögliche Fehler. Dieser Fehler hat keine Auswirkungen auf die Zuverlässigkeit des Systems.
Die Option -javahome in Solaris- und Windows-Skripts (alle Versionen) funktioniert nicht, wenn der bereitgestellte Wert ein Leerzeichen enthält (Fehlernummer 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. Beachten Sie, dass die Clientanwendung immer alle Nachrichten aus der Warteschlange abruft. Über das Attribut imqQueueBrowserMaxMessagesPerRetrieve wird festgelegt, wie die in der Wartschlange enthaltenen Nachrichten aufgeteilt werden, die an die Client-Runtime gesendet werden müssen (einige große Chunks oder viele kleine Chunks), die Gesamtzahl der Nachrichten bleibt jedoch gleich. Eine Änderung des Attributwerts kann sich auf die Leistung auswirken, führt jedoch nicht dazu, dass die Clientanwendung mehr oder weniger Daten abruft (Fehlernummer 6387631).
Die nachfolgend beschriebenen Probleme beziehen sich auf den Message Queue-Broker.
Der imqbrokerd —Lizenz-Befehl zeigt veraltete und doppelte Informationen an. Auch wenn diese Lizenzart nicht mehr unterstützt wird, werden Informationen zur Testlizenz (Fehlernummer 6489711) und doppelte Informationen zur UNL-Lizenz (Fehlernummer 6441015 angezeigt.
Umgehung Es handelt sich um ein kosmetisches Problem, das keine Umgehung erfordert.
Der Broker überschreitet das 1000 Nachrichten-Limit für die Warteschlange mit gelöschten Nachrichten; es werden weiterhin Nachrichten in die Warteschlange mit gelöschten Nachrichten eingefügt, bis der Broker keinen freien Speicherplatz mehr aufweist. (Fehlernummer 6502744)
Umgehung Setzen Sie das Limit für Nachrichten in der Warteschlange mit gelöschten Nachrichten auf 1001 oder einen anderen Wert als 1000.
HTTPS createQueueConnection verursacht gelegentlich einen Ausnahmefehler unter Windows 2000 (Fehlernummer 4953348).
Umgehung Stellen Sie die Verbindung erneut her.
Wenn Sie den Broker mit der Tastenkombination Strg-C beenden, werden die Transaktionen nach dem Schließen des Speichers eventuell bereinigt (Fehlernummer 4934446).
Der Broker zeigt eventuell Fehler mit dem Text "Speichermethodenzugriff nach Beendigung des Speichers",sofern der Broker geschlossen wird, während Nachrichten oder Transaktionen verarbeitet werden.
Umgehung Sie können diese Fehlermeldung ignorieren. Der Broker informiert die Verbraucher ordnungsgemäß über mögliche Fehler. Dieser Fehler hat keine Auswirkungen auf die Zuverlässigkeit des Systems.
Wenn der Persistenzspeicher zu viele Zielstandorte öffnet, kann auf den Broker nicht mehr zugegriffen werden (Fehlernummer 4953354).
Workaround 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.
Verbraucher verwaisen, wenn ein Zielstandort gelöscht wird (Fehlernummer 5060787).
Aktive Verbraucher verwaisen, wenn ein Zielstandort gelöscht wird. Ein verwaister Verbraucher erhält keine Meldungen mehr (auch dann nicht, wenn der Zielstandort neu erstellt wird).
Umgebung Derzeit gibt es keine Umgehung für dieses Problem.
Die Nachrichtenauswahl mit JMSMessageID funktioniert nicht (Fehlernummer 6196233).
Umgehung Ändern Sie die Auswahl über den folgenden Ausdruck
JMSMessageID = "ID:message-id-string"
folgendermaßen ab
JMSMessageID IN ('ID:message-id-string', 'message-id-string')
Message Queue - Ein Warteschlangen-Browser zeigt nicht verarbeitete Nachrichten (Fehlernummer 6264003).
Beim Durchsuchen der Inhalte einer Warteschlange werden Nachrichten, die im Rahmen einer Transaktion erzeugt, aber noch nicht verarbeitet wurden, im Warteschlangen-Browser aufgelistet.
Umgehung Derzeit gibt es keine Umgehung für dieses Problem.
Wenn der Broker während der Verarbeitung abstürzt, stehen Nachrichten möglicherweise nicht mehr zur Verfügung (Fehlernummer 6467874).
In Ausnahmefällen stehen Nachrichten während des Broker-Absturzes für Benutzer nicht mehr zu Verfügung. Insbesondere während eines kurzen Zeitfensters im Verarbeitungsprozesses kann es vorkommen, dass die Nachricht im persistenten Speicher verbleibt. Wenn dieser Fall eintritt, wird beim Start des Brokers nach einem Absturz die folgende Nachricht angezeigt.
[06/Sep/2006:10:11:11 PDT] ERROR [B2085]: Laden von Ziel q0 [Queue] fehlgeschlagen. Die auf diesem Ziel gespeicherten Nachrichten sind nicht verfügbar: > com.sun.messaging.jmq.jmsserver.util.BrokerException: Mit der Nachricht 8-129.145.180.87(b8:8b:26:15:41:26)-38998-1157562551217 ist bereits eine Bestätigungsliste verbunden.
Umgehung Derzeit gibt es keine Umgehung für dieses Problem.
Es gibt kein eigenständiges Produkt für die Beta-Version von Message Queue 3.7 UR1. Für diese Version müssen Sie Message Queue über das Installationsprogramm von Java Enterprise System Installer installieren un die Anweisungen im Sun Java System Installation Guide befolgen.