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

Verarbeitung von Nachrichten im Modus ohne ASF

Im Modus ohne ASF-Modus sind Threads aktiv aktiv, sobald der Listener-Port gestartet wird. Die Anzahl aktiver Threads wird durch den Wert bestimmt, der für die Eigenschaft Maximale Anzahl Sitzungen festgelegt wurde. Unabhängig von der Anzahl der Nachrichten, die verarbeitet werden müssen, ist immer die mit der Eigenschaft Maximale Anzahl Sitzungen angegebene Anzahl an Threads aktiv. Jeder aktive Thread ist eine individuelle physische Netzverbindung.

Wenn Sie IBM MQ Version 7.0 oder höher als Messaging-Provider verwenden, können bis zu zehn Threads eine einzige physische Netzverbindung gemeinsam nutzen.

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.

Nachrichtenverarbeitung im Modus ohne ASF

Sie aktivieren den Modus ohne ASF, indem Sie einen Wert ungleich null für die angepasste Eigenschaft NON.ASF.RECEIVE.TIMEOUT des Nachrichten-Listener-Service angeben. NON.ASF.RECEIVE.TIMEOUT dient als Schalter, der den ASF-Modus inaktiviert, und als Zeitlimitwert für die Methode receive().

Anmerkung: Die folgenden angepassten Eigenschaften des Nachrichten-Listener-Service funktionieren im Modus ohne ASF nicht:
  • SERVER.SESSION.POOL.REAP
  • SERVER.SESSION.POOL.UNUSED.TIMEOUT
  • SERVER.SESSION.POOL.UNUSED.TIMEOUT.Ipaname

Die folgende Abbildung veranschaulicht, wie die Nachrichtenverarbeitung zwischen WebSphere Application Server und IBM MQ im Modus ohne ASF stattfindet:

Abbildung 1. Nachrichtenverarbeitung im Modus ohne ASF
[AIX Solaris HP-UX Linux Windows][IBM i]Die Abbildung wird im Begleittext beschrieben.
Wie in der Abbildung gezeigt, werden die Nachrichten wie folgt verarbeitet, wenn der Nachrichten-Listener-Service im Modus ohne ASF arbeitet:
  1. Wenn der Listener-Port gestartet wird, erhält er einen Thread aus dem Thread-Pool des Nachrichten-Listener-Service ab.
  2. Der Listener-Port öffnet eine Verbindung zum IBM MQ-Warteschlangenmanager im Thread und erstellt einen JMS-Nachrichtenkonsumenten. Der Nachrichtenkonsument wartet auf Nachrichten am JMS-Ziel, für das der Listener-Port konfiguriert ist.
  3. Der Listener-Port erstellt eine Transaktion, um die Nachrichtenverarbeitung zu verwalten.
  4. Der Thread ruft die Methode receive() im Nachrichtenkonsumenten auf, um auf Nachrichten am Ziel zu warten. Wenn die Methode receive() in dem mit NON.ASF.RECEIVE.TIMEOUT angegebenen Zeitraum keine Nachricht erkennt, macht der Anwendungsserver die aktive Transaktion rückgängig und startet eine neue. Anschließend ruft der Thread die Methode receive() erneut auf.
  5. Wenn der Nachrichtenkonsument eine Nachricht erkennt, prüft er, ob die Nachricht für die MDB, die den Listener-Port verwendet, geeignet ist.
  6. Wenn die Nachricht geeignet ist, entnimmt die Methode receive() sie dem Ziel und sendet sie an den Thread.
  7. Der Thread ruft die Methode onMessage() der MDB im Nachrichtenkonsumenten auf, und die Nachricht wird verarbeitet.
  8. Nachdem die Nachricht erfolgreich verarbeitet wurde, wird die Transaktion festgeschrieben. Wird die Nachricht nicht erfolgreich verarbeitet, wird die Transaktion rückgängig gemacht.
  9. Es wird eine neue Transaktion gestartet, und der Nachrichtenkonsument ruft die Methode receive() auf, um auf neue Nachrichten zu warten.
Die Anzahl der Threads, die eine MDB gleichzeitig verarbeiten kann, wird mit dem Wert der Eigenschaft Maximale Anzahl Sitzungen für den Listener-Port festgelegt werden. Wenn Sie Maximale Anzahl Sitzungen auf den Standardwert 1 setzen, kann die MDB nur jeweils eine einzige Nachricht verarbeiten. Wenn Sie mehrere Nachrichten gleichzeitig verarbeiten möchten, können Sie dies im ASF-Modus zulassen, indem Sie Maximale Anzahl Sitzungen auf einen höheren Wert als 1 setzen. Setzen Sie Maximale Anzahl Sitzungen beispielsweise auf 2 setzen, werden Nachrichten wie folgt verarbeitet:
  1. Wenn der Listener-Port gestartet wird, erhält er zwei Threads aus dem Thread-Pool des Nachrichten-Listener-Service ab.
  2. Der Listener-Port erstellt einen Nachrichtenkonsumenten und eine Transaktion in jedem Thread. Die Nachrichtenkonsumenten warten auf Nachrichten am Ziel, für das der Listener-Port konfiguriert ist.
  3. Beide Nachrichtenkonsumenten rufen die Methode receive() auf, um am Ziel auf Nachrichten zu warten. Die Konsumemten konkurrieren um den Erhalt von Nachrichten vom Ziel.
  4. Wenn einer der Konsumenten die Nachricht erfolgreich abruft, verarbeitet er sie, indem er die Methode onMessage() der MDB aufruft. Der andere Nachrichtenkonsument ruft die Methode receive() weiter auf, um auf Nachrichten am Ziel zu warten.

Unerwünschte Transaktionszeitlimitüberschreitungen vermeiden

Wenn Ihr Messaging-System im Modus ohne ASF ausgeführt wird, müssen Sie, um nicht erwünschte Transaktionszeitlimitis zu vermeiden, ausreichend Zeit für die Verarbeitung zulassen, bevor das Zeitlimit für die Gesamtlebensdauer der Transaktion erreicht wird. Vergewissern Sie sich, dass der für die angepasste Eigenschaft NON.ASF.RECEIVE.TIMEOUT des Nachrichten-Listener-Service angegebene Wert kleiner ist als der Wert für die Eigenschaft Zeitlimit für Gesamtlebensdauer der Transaktion des Transaktionsservice und dass die Differenz zwischen den Werten der zwei Eigenschaften größer ist als der Wert für den Zeitraum, den die Methode onMessage() Ihrer MDB benötigt, um die Nachricht zu verarbeiten.

Wie das folgende Beispiel zeigt, können Transaktionen ein Zeitlimit überschreiten, bevor sie abgeschlossen sind, wenn diese Eigenschaften nicht ordnungsgemäß konfiguriert sind. Das liegt daran, dass der Thread mit dem Aufruf der Methode receive() beginnt, sobald die Transaktion erstellt wird. Im folgenden Beispiel ist der Parameter NON.ASF.RECEIVE.TIMEOUT auf 110000 Millisekunden (110 Sekunden) und der Parameter Zeitlimit für Gesamtlebensdauer der Transaktion auf 120 Sekunden gesetzt, und die Methode onMessage() der MDB benötigt 15 Sekunden, um eine Nachricht zu verarbeiten. Das Beispiel setzt voraus, dass eine Nachricht am Ziel erst erscheint, wenn die Methode receive() das Zeitlimit beinahe überschritten hat:
  1. Der Listener-Port wird gestartet. Er ordnet einen Thread aus dem Thread-Pool zu und erstellt eine Transaktion und einen Nachrichtenkonsumenten im Thread.
  2. Der Thread ruft die Methode receive() auf, um die Empfangsbereitschaft für Nachrichten sicherzustellen.
  3. Nach 110 Sekunden erscheint eine Nachricht am Ziel.
  4. Der Thread entfernt die Nachricht aus dem Ziel und ruft die Methode onMessage() der MDB auf, um mit der Verarbeitung der Nachricht zu beginnen.
  5. Zehn Sekunden später ist das Transaktionszeitlimit erreicht. Der Anwendungsserver markiert die Transaktion für den Rollback.
  6. Fünf Sekunden später beendet die Methode onMessage() die Verarbeitung der Nachricht und versucht, die Transaktion festzuschreiben.
  7. Der gesamte Zeitraum, der seit dem Start der Transaktion verstrichen ist, beträgt 125 Sekunden (110 Sekunden auf eine Nachricht warten und 15 Sekunden zur Verarbeitung der Nachricht). Da dieser Zeitraum länger ist als das Transaktionszeitlimit, verhindert der Anwendungsserver, dass die Transaktion festgeschrieben wird, und sie wird zurückgesetzt.

Weitere Informationen zum Konfigurieren der Eigenschaften NON.ASF.RECEIVE.TIMEOUT und Zeitlimit für Gesamtlebensdauer der Transaktion zum Vermeiden unerwünschter Transaktionszeitlimitüberschreitungen finden Sie unter "Zugehörige Tasks".


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=cmb_asfnonasf_nonasf
Dateiname:cmb_asfnonasf_nonasf.html