Freigeben über

Server-Side Fehler

Der Zuhörer und Spieler arbeiten zusammen, um mit Giftbotschaften umzugehen. Wenn eine Transaktion, die wiedergegeben wird, fehlschlägt, verschiebt Message Queuing die Eingabenachricht zurück in die Eingabewarteschlange. Der Spieler bricht die Transaktion ab, wenn sie ein fehlerhaftes HRESULT von der Serverkomponente empfängt oder eine Ausnahme abfangen. Wenn das Problem weiterhin besteht, könnte der Listener im folgenden Muster fortlaufend schleife:

  • Dequeues der Nachricht
  • Instanziiert das Objekt.
  • Leidet an einem Rollback
  • Platziert die Nachricht wieder oben in der Warteschlange.

Der Dienst für in die Warteschlange eingereihte Komponenten verarbeitet diesen Fehler mithilfe einer Reihe anwendungsspezifischer Wiederholungswarteschlangen. Wenn die Komponente installiert wird, gibt es sieben Warteschlangen für jede Anwendung, wie folgt:

  1. Die normale Eingabewarteschlange. Der Name dieser Warteschlange ist der NAME der COM+-Anwendung. Dies ist eine öffentliche Message Queuing-Warteschlange.

  2. Die erste Wiederholungswarteschlange. Nachrichten werden hier verschoben, wenn die Transaktion beim Verarbeiten von Nachrichten aus der normalen Eingabewarteschlange wiederholt fehlschlägt. Nachrichten in dieser Warteschlange werden nach einer Minute verarbeitet. Eine Nachricht kann dreimal in dieser Warteschlange wiederholt werden, bevor sie in die Rückseite der zweiten Wiederholungswarteschlange verschoben wird. Diese Warteschlange heißt ApplicationName_0. Diese Warteschlange ist eine private Message Queuing-Warteschlange.

  3. Die zweite Wiederholungswarteschlange. Nachrichten werden hier verschoben, wenn die Transaktion beim Verarbeiten von Nachrichten aus der ersten Wiederholungswarteschlange wiederholt fehlschlägt. Nachrichten in dieser Warteschlange werden nach zwei Minuten verarbeitet. Eine Nachricht kann dreimal in dieser Warteschlange wiederholt werden, bevor sie zur Rückseite der dritten Wiederholungswarteschlange verschoben wird. Diese Warteschlange heißt ApplicationName_1. Diese Warteschlange ist eine private Message Queuing-Warteschlange.

  4. Die dritte Wiederholungswarteschlange. Nachrichten werden hier verschoben, wenn die Transaktion beim Verarbeiten von Nachrichten aus der zweiten Wiederholungswarteschlange wiederholt fehlschlägt. Nachrichten in dieser Warteschlange werden nach vier Minuten verarbeitet. Eine Nachricht kann dreimal in dieser Warteschlange wiederholt werden, bevor sie zur Rückseite der vierten Wiederholungswarteschlange verschoben wird. Diese Warteschlange heißt ApplicationName_2. Diese Warteschlange ist eine private Message Queuing-Warteschlange.

  5. Die vierte Wiederholungswarteschlange. Nachrichten werden hier verschoben, wenn die Transaktion beim Verarbeiten von Nachrichten aus der dritten Wiederholungswarteschlange wiederholt fehlschlägt. Nachrichten in dieser Warteschlange werden nach acht Minuten verarbeitet. Eine Nachricht kann dreimal in dieser Warteschlange wiederholt werden, bevor sie in die fünfte Wiederholungswarteschlange verschoben wird. Diese Warteschlange heißt ApplicationName_3. Diese Warteschlange ist eine private Message Queuing-Warteschlange.

  6. Die fünfte Wiederholungswarteschlange. Nachrichten werden hier verschoben, wenn die Transaktion beim Verarbeiten von Nachrichten aus der vierten Wiederholungswarteschlange wiederholt fehlschlägt. Nachrichten in dieser Warteschlange werden nach sechszehn Minuten verarbeitet. Eine Nachricht kann dreimal in dieser Warteschlange wiederholt werden, bevor sie in die letzte ruhende Warteschlange verschoben wird. Diese Warteschlange heißt ApplicationName_4. Dies ist eine private Message Queuing-Warteschlange.

  7. Eine anwendungsspezifische endgültige Restwarteschlange. Nachrichten werden hier verschoben, wenn die Transaktion beim Versuch in der fünften Wiederholungswarteschlange wiederholt abgebrochen wird. Diese Warteschlange wird ApplicationName-_DeadQueue benannt. Dies ist eine private Message Queuing-Warteschlange. Die letzte ruhende Warteschlange wird nicht von einem Warteschlangenlistener gewartet. Nachrichten bleiben hier, bis sie manuell verschoben werden (z. B. durch das Hilfsprogramm für nachrichtenverschiebungswarteschlangen in der Warteschlange) oder vom Message Queuing-Explorer gelöscht werden.

Nachrichten, die nicht abgespielt werden können, da klar ist, dass jeder Wiederholungsversuch fehlschlägt, kann direkt in die anwendungsspezifische endgültige Restingwarteschlange verschoben werden, ohne dass alle Wiederholungsstufen durchlaufen werden.

Der Spieler gibt ein COM+-Ereignis aus, um interessierte Parteien darüber zu informieren, dass Nachrichten nicht wiedergegeben werden können. COM+-Ereignisse werden in den folgenden Situationen ausgegeben:

  • Wenn eine Transaktion abgebrochen wird
  • Wenn eine Nachricht von einer Warteschlange in eine andere verschoben wird
  • Wenn eine Nachricht in der endgültigen ruhenden Warteschlange abgelegt wird

Nachrichten können geändert werden, bevor sie von einer Warteschlange in eine andere verschoben werden. Der Sicherheitsmechanismus für COM+-Komponenten in der Warteschlange ermöglicht das Verschieben einer Nachricht in Wiederholungswarteschlangen und anschließendes Erneutes Einfügen in die anfängliche Eingabewarteschlange der Anwendung. Weitere Informationen zur Sicherheit von Komponenten in der Warteschlange finden Sie unter Securityin der Warteschlange.

Wiederholungswarteschlangen werden zusammen mit der Hauptanwendungswarteschlange erstellt, wenn die Anwendung entweder vom Verwaltungstool für Komponentendienste oder mithilfe der COM+ Administrative SDK-Funktionen als Warteschlange gekennzeichnet wird. Der Dienst für in die Warteschlange eingereihte Komponenten ermöglicht flexibilität im Wiederholungsmechanismus, indem wiederholungswarteschlangen gelöscht werden können. Wenn z. B. alle Wiederholungswarteschlangen gelöscht werden, wird eine Meldung, die dauerhaft abgebrochen wird, direkt aus der Anwendungswarteschlange in die anwendungsspezifische endende Restingwarteschlange verschoben. Durch Entfernen einer oder mehrerer Wiederholungswarteschlangen kann die Anzahl und Länge der Wiederholungsversuche reduziert werden. Wenn Warteschlangen aus der Wiederholungssequenz entfernt werden, entspricht die Anzeigedauer der verbleibenden Warteschlangen der Position in der Sequenz der Wiederholungswarteschlangen. Wenn Sie beispielsweise die Wiederholungswarteschlange ApplicationName_1, ApplicationName_2 und ApplicationName_3 entfernen, werden die Nachrichten auf ApplicationName_4 so verarbeitet, als wäre die Warteschlange die zweite Wiederholungswarteschlange.

Der Wiederholungsmechanismus ist so konzipiert, dass eine Nachricht nach Möglichkeit abgeschlossen wird. In einigen Fällen ist es möglicherweise nicht möglich, dass die Nachricht erfolgreich ist. Beispielsweise kann ein Kunde versuchen, Geld von einem Konto zu widerrufen, das über unzureichende Mittel verfügt. Unter diesen Umständen können Sie den Fehler auf verschiedene Arten behandeln, einschließlich der folgenden:

  • Generieren einer Diagnose und Ausgeben einer Warnung
  • Erstellen einer Ausgleichstransaktion
  • Ignorieren des Problems und Schließen der Nachricht

Wie clientseitige persistente Fehler ermöglicht der Dienst für in die Warteschlange eingereihte Komponenten eine Ausnahmeklasse, die einer Komponente zugeordnet werden kann. Die Ausnahmeklasse wird der Komponente mithilfe der Registerkarte Erweiterten auf der Seite "Komponenteneigenschaften" des Verwaltungstools für Komponentendienste oder mithilfe der COM+-Verwaltungsfunktionen zugeordnet. Die Ausnahmeklasse ermöglicht es dem Entwickler, die Kontrolle zu erhalten, nachdem eine Nachricht erneut versucht wurde, und bevor diese Nachricht in die anwendungsspezifische endgültige Restwarteschlange verschoben wird. Weitere Informationen zur Ausnahmeklasse finden Sie unter Persistent Client-Side Failures.

Es folgt die Abfolge von Ereignissen für die serverseitige Ausnahmebehandlung:

  1. Die Nachricht wird durch die verfügbaren anwendungsspezifischen Wiederholungswarteschlangen verschoben.
  2. Der letzte Wiederholungsversuche in der letzten Wiederholungswarteschlange schlägt fehl.
  3. Die Laufzeit des Diensts für in die Warteschlange eingereihte Komponenten ruft die Zielkomponente aus der Nachricht ab und sucht nach einer Ausnahmeklasse.
  4. Die Laufzeit instanziiert die Ausnahmeklasse.
  5. Die Laufzeitabfragen IPlaybackControl für die Ausnahmeklasse.
  6. Die Laufzeit ruft IPlaybackControl::FinalServerRetry in der Ausnahmeklasse auf.
  7. Die Laufzeit gibt alle Eigenschafts- und Methodenaufrufe aus der Nachricht an die Ausnahmeklasse wieder.
  8. Wenn die Schritte 4 bis 6 nicht erfolgreich sind, verschiebt die Laufzeit die Nachricht in die anwendungsspezifische endende Restwarteschlange.

Wenn Sie in den oben beschriebenen Prozess eingreifen müssen oder eine Giftnachricht aus der endgültigen ruhenden Warteschlange verschieben müssen, verwenden Sie das Hilfsprogramm "Message Mover". Weitere Informationen zum Nachrichtenverschiebungsprogramm finden Sie unter Behandeln von Fehlern.

Client-Side Fehler

Client-Side fehler