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 Broker kann bei Verwendung von HADB ausschließlich Nachrichten bis zu einer Größe von 10 MB verarbeiten. (Fehler 6531734)
Wenn ein Client mit einem Hochverfügbarkeits-Broker verbunden ist, versucht die Client-Laufzeit solange die Verbindung wiederherzustellen, bis sie erfolgreich war (unabhängig davon, auf welchen Wert imqAddressListIterations gesetzt ist).
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.
Wenn Sie in einem konventionellen Cluster einen 4.1-Broker mit einem 3.x-Broker clustern möchten, müssen Sie die Eigenschaft imq.autocreate.queue.maxNumActiveConsumers=1 für den 4.1-Broker setzen. Anderenfalls werden die Broker keine Clusterverbindung herstellen können.
Beim Konvertieren in einen Hochverfügbarkeits-Cluster können Sie das Message Queue-Manger-Dienstprogramm (imqdbmgr) verwenden, um einen vorhandenen eigenständigen persistenten HADB-Datenspeicher in einen gemeinsam genutzten HADB-Speicher zu konvertieren. Der Befehl lautet wie folgt.
imqdbmgr upgrade hastore
Dieses Dienstprogramm können Sie in den folgenden Fällen verwenden.
Für den Wechsel von einem eigenständigen HADB-Speichers der Version 4.0 zu einen gemeinsam genutzten HADB-Speicher der Version 4.1. In diesem Fall wird der Broker den Speicher automatisch aktualisieren. Anschließend können Sie den imqdbmgr-Befehl ausführen, um den aktualisierten Datenspeicher für die gemeinsame Nutzung zu konvertieren.
Für den Wechsel von einem eigenständigen HADB-Speichers der Version 4.1 zu einen gemeinsam genutzten HADB-Speicher. In diesem Fall müssen Sie lediglich den oben gezeigten imqdbmgr-Befehl ausführen, um den Datenspeicher für die gemeinsame Nutzung zu konvertieren.
Da dieser Befehl lediglich die Umwandlung von HADB-Speichern unterstützt, ist es nicht möglich, damit dateibasierte Speicher oder andere JDBC-Speicher in einen gemeinsam genutzten HADB-Speicher zu konvertieren. Wenn Sie vorher eine 3.x-Version von Message Queue ausgeführt haben, müssen Sie einen HADB-Speicher erstellen und anschließend die Daten manuell zu diesem Speicher migrieren, um die Hochverfügbarkeits-Funktion zu nutzen.
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. (Fehlernummer 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." aus. (Fehlernummer 6550483)
Weitere Informationen finden Sie unter "HADB Problems" im Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.
In einem Broker-Cluster fügt ein Broker Nachrichten zu einer Warteschlange für eine Remote-Verbindung hinzu, die noch nicht hergerstellt wurde (Fehlernummer 4951010).
Umgehung Die Meldungen werden vom Konsumenten empfangen, sobald die Verbindung hergestellt ist. 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 imq.txn.reapLimit-Eigenschaft.