Broker-Cluster

Folgende Probleme betreffen Broker-Cluster.

• High Availability Broker mit MySQL Cluster-Datenspeicher kann nicht neu starten, wenn er nicht ordnungsgemäß beendet wurde (Fehler 6896877)

  Umgehung: Dieses Problem wird durch ein bekanntes Problem im MySQL Cluster verursacht (http://bugs.mysql.com/bug.php?id=47955). Dieses Problem wurde in den MySQL-Versionen 5.1.39-ndb-6.3.28 , 5.1.39-ndb-7.0.9 und 5.1.39-ndb-7.1.0 behoben.

• 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 erweiterten Broker-Cluster verbunden ist, versucht die Client-Laufzeit, solange eine Verbindung herzustellen, bis sie Erfolg hat (der Wert des Verbindungsfactory-Attributs 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, das Broker der Version 4.3 enthält, müssen alle Broker Version 3.5 oder höher aufweisen.

• Message Queue 4.3-, 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: Stellen Sie sicher, dass der Wert von imq.autocreate.queue.maxNumActiveConsumers bei allen Brokern gleich ist. Normalerweise erfolgt dies, indem die Konfiguration von Message Queue 4.3, 4.2 und 4.1 an diejenige angepasst wird, die von Brokern der Version 3.7 oder 3.6 verwendet wird (standardmäßig wird der Wert -1 zum Standardwert 1 der vorhergehenden Version geändert).

• Um einen Broker für Message Queue 4.3 (oder 4.x) einem Broker-Cluster für Message Queue 3.x hinzuzufügen, muss mindestens ein Masterbroker ausgeführt werden. (Fehler 6763796)

• Bei der Konvertierung aus einem konventionellen Cluster in einen erweiterten Cluster können Sie mit dem Datenbank-Manager-Dienstprogramm von Message Queue (imqdbmgr) einen bestehenden eigenständigen JDBC-basierten Datenspeicher in einen gemeinsam genutzten JDBC-Datenspeicher konvertieren, wie in Cluster Conversion: JDBC-Based Data Store in Sun GlassFish Message Queue 4.4 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: Table memory space exhausted" (Kein Tabellenspeicher verfügbar) aus. (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 stellt ein Broker die Nachrichten an eine entfernte Verbindung, die noch nicht geöffnet wurde, in eine Warteschlange. (Fehler 4951010)

  Umgehung: Der Konsument erhält die Nachrichten, sobald die Verbindung geöffnet wurde. Die Nachrichten werden an einen anderen Konsumenten gesendet, wenn die Verbindung des Konsumenten geschlossen bleibt.

• 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]: 
  Message acknowledgement failed from 
  mq://129.145.130.95:7677/?instName=a&brokerSessionUID=3209681167602264320:
      ackStatus = NOT_FOUND(404)\
      Reason = Update remote transaction state to COMMITED(6): 
  transaction 3534784765719091968 not found, the transaction
  may have already been committed.
      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 Notify commit transaction 
  [8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690, 
  [consumer:3534784765719133952, type=NONE]]
  TUID=3534784765719091968 got response: 
  com.sun.messaging.jmq.jmsserver.util.BrokerException:
   Update remote transaction state to COMMITED(6): 
    transaction 3534784765719091968 not found, the transaction may have already 
    been committed.:
  com.sun.messaging.jmq.jmsserver.util.BrokerException: Update remote transaction 
  state to COMMITED(6): transaction 3534784765719091968 not found, the transaction
   may have already been committed.r

  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.