[AIX Solaris HP-UX Linux Windows][IBM i]

Strikte Nachrichtenreihenfolge bei Verwendung von Listener-Ports ohne ASF

Eine strikte Nachrichtenreihenfolge kann erreicht werden, wenn MDB-Anwendungen im IBM MQ-Messaging-Provider implementiert werden, falls in der Anwendung keine besonderen Funktionen zur Bearbeitung ungeordnet eingehender Nachrichten codiert wurden.

In WebSphere Application Server Version 7 und höher sind Listener-Ports stabilisiert. Weitere Informationen finden Sie im Artikel zu den stabilisierten Features. Deshalb sollten Sie die Migration Ihrer WebSphere MQ-MDB-Implementierungskonfigurationen von Listener-Ports auf Aktivierungsspezifikationen planen. [AIX Solaris HP-UX Linux Windows][IBM i]Weitere Informationen zum Konfigurieren der Aktivierungsspezifikationen für Nicht-ASF-Modus finden Sie unter Aktivierungsspezifikation für Nicht-ASF-Modus konfigurieren. Sie sollten die Migration jedoch erst dann durchführen, wenn Sie sicher sind, dass die Anwendung nicht in Anwendungsservern einer früheren Version als WebSphere Application Server Version 7 ausgeführt werden muss. Wenn beispielsweise in einem Anwendungs-Server-Cluster einige Member Version 6.1 und andere Member eine höhere Version haben, sollten Sie Anwendungen in diesem Cluster erst dann auf die Verwendung von Aktivierungsspezifikationen migrieren, wenn Sie alle Anwendungsserver im Cluster auf die höhere Version migriert haben.

Für dieses Szenario gelten folgende Voraussetzungen:
  • Die MDB-Anwendung ist transaktionsorientiert.
  • Der Rücksetzschwellenwert (BOTHRESH) in der IBM MQ-Warteschlange wurde auf 0 gesetzt.

Konfiguration von WebSphere Application Server für geordnete Übermittlung

  • Der Modus ohne ASF muss aktiviert werden, indem ein Zeitlimit ungleich null für die angepasste Eigenschaft NON.ASF.RECEIVE.TIMEOUT des Nachrichten-Listener-Service von IBM MQ angegeben wird.
  • Die Einstellung Maximale Anzahl Sitzungen für den Listener-Port muss auf 1 gesetzt sein.
  • Für den Listener-Port ohne ASF, dessen Einstellung Maximale Anzahl Sitzungen den Wert 1 hat, wird in dem Anwendungsserver, der Nachrichten abruft, ein einzelner Thread ausgeführt. Wenn eine Nachricht eingeht, übermittelt der Thread sie sofort an die MDB.
  • Der Warteschlangenmanager betrachtet diesen Thread als einzige Anwendung, die Nachrichten abruft, daher werden die Nachrichten nacheinander verarbeitet.

Nachrichten können bei dieser Implementierung während einer Transaktionswiederherstellung ungeordnet eingehen

Es muss eine bestimmte Gruppe von Ereignissen in einer bestimmten Reihenfolge eintreten, damit dieses Szenario entsteht. Daher kann dieses Szenario als ungewöhnlich eingestuft werden. Sollte die Einhaltung der Reihenfolge bei der Nachrichtenübermittlung für die Ausführung Ihrer Anwendung jedoch kritisch sein, müssen Sie dies berücksichtigen.

  • Eine Nachrichtenzustellung außerhalb der Reihenfolge kann bei dieser Implementierungsoption während der Wiederherstellung nach einem Fehler in einer der folgenden Komponenten auftreten:
    • Anwendungsserver, in dem die MDB ausgeführt wird
    • IBM MQ-Warteschlangenmanager
    • Netz, das den Anwendungsserver und den Warteschlangenmanager miteinander verbindet
  • Wenn eine dieser Komponenten mitten in der zweiphasigen Festschreibung einer MDB-Transaktion ausfällt, stellt der Transaktionsmanager des Anwendungsservers seine Verbindung zum Warteschlangenmanager wieder her, um die Transaktion aufzulösen, sobald die Komponente wieder verfügbar ist.
  • Dieser Wiederherstellungsprozess ist asynchron und es ist möglich, dass die Zustellung neuer Nachrichten an die MDB beginnt, bevor der Transaktionswiederherstellungsprozess abgeschlossen ist. Wenn das Ergebnis der Transaktionswiederherstellung ein Rollback der Transaktion ist, wird die Nachricht an die WebSphere MQ-Warteschlange zurückgegeben und der Anwendung erneut zugestellt. Dies geschieht möglicherweise, nachdem bereits neue Nachrichten zugestellt wurden.

Hinweise für eine Clusterimplementierung

Wenn Sie ASF-Listener-Ports verwenden, können Sie die Standardoption für gemeinsame Nutzung (DEFSOPT) für die Warteschlange auf exclusive setzen. Wenn Sie diese Option bei der Clusterimplementierung einer Anwendung auswählen, können alle Cluster-Member bis auf eines ihre Listener-Ports nicht starten. Die Cluster-Member generieren eine Ausnahmebedingung des Typs 2042MORC_OBJECT_IN_USE in der Nachricht WMSG0057E.

Wenn diese Ausnahmebedingung eintritt, können Sie das automatische Failover für die Anwendung konfigurieren, indem Sie die folgende angepasste Eigenschaft des Nachrichten-Listener-Service in WebSphere Application Server konfigurieren:

MAX.RECOVERY.RETRIES
Legen Sie unter MAX.RECOVERY.RETRIES einen hohen Wert für die Nachrichten-Listener-Services aller Server im Cluster fest. Der Maximalwert für MAX.RECOVERY.RETRIES ist 2147483647.
Die angepasste Eigenschaft MAX.RECOVERY.RETRIES des Nachrichten-Listener-Service muss zusammen mit einem entsprechenden Wert der angepassten Eigenschaft MAX.RECOVERY.INTERVAL des Nachrichten-Listener-Service angegeben werden. Der maximal zulässige Zeitraum, in dem ein Listener-Port versuchen kann, die Wiederherstellung durchzuführen, ohne dass er gestoppt und erneut gestartet wird, errechnet sich aus dem Wert "2147483647" multipliziert mit dem für MAX.RECOVERY.INTERVAL angegebenen Wert. In dieser Konfiguration versucht jedes Cluster-Member kontinuierlich, seinen Listener-Port zu starten, bis das aktive Cluster-Member gestoppt wird und der Warteschlangenmanager zulässt, dass es als einzelner ausschließlicher Konsument eine Verbindung herstellt.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cmm_wmq_smo_nonasflp
Dateiname:cmm_wmq_smo_nonasflp.html