![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
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. 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().
- 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:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)

- Wenn der Listener-Port gestartet wird, erhält er einen Thread aus dem Thread-Pool des Nachrichten-Listener-Service ab.
- 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.
- Der Listener-Port erstellt eine Transaktion, um die Nachrichtenverarbeitung zu verwalten.
- 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.
- Wenn der Nachrichtenkonsument eine Nachricht erkennt, prüft er, ob die Nachricht für die MDB, die den Listener-Port verwendet, geeignet ist.
- Wenn die Nachricht geeignet ist, entnimmt die Methode receive() sie dem Ziel und sendet sie an den Thread.
- Der Thread ruft die Methode onMessage() der MDB im Nachrichtenkonsumenten auf, und die Nachricht wird verarbeitet.
- Nachdem die Nachricht erfolgreich verarbeitet wurde, wird die Transaktion festgeschrieben. Wird die Nachricht nicht erfolgreich verarbeitet, wird die Transaktion rückgängig gemacht.
- Es wird eine neue Transaktion gestartet, und der Nachrichtenkonsument ruft die Methode receive() auf, um auf neue Nachrichten zu warten.
- Wenn der Listener-Port gestartet wird, erhält er zwei Threads aus dem Thread-Pool des Nachrichten-Listener-Service ab.
- 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.
- Beide Nachrichtenkonsumenten rufen die Methode receive() auf, um am Ziel auf Nachrichten zu warten. Die Konsumemten konkurrieren um den Erhalt von Nachrichten vom Ziel.
- 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.
- Der Listener-Port wird gestartet. Er ordnet einen Thread aus dem Thread-Pool zu und erstellt eine Transaktion und einen Nachrichtenkonsumenten im Thread.
- Der Thread ruft die Methode receive() auf, um die Empfangsbereitschaft für Nachrichten sicherzustellen.
- Nach 110 Sekunden erscheint eine Nachricht am Ziel.
- Der Thread entfernt die Nachricht aus dem Ziel und ruft die Methode onMessage() der MDB auf, um mit der Verarbeitung der Nachricht zu beginnen.
- Zehn Sekunden später ist das Transaktionszeitlimit erreicht. Der Anwendungsserver markiert die Transaktion für den Rollback.
- Fünf Sekunden später beendet die Methode onMessage() die Verarbeitung der Nachricht und versucht, die Transaktion festzuschreiben.
- 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".