Freigeben über

Server-Side Fehler

  • Artikel

Der Listener und Spieler arbeiten zusammen, um mit Giftnachrichten zu arbeiten. 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 es eine fehlgeschlagene HRESULT aus der Serverkomponente empfängt oder eine Ausnahme abfangen. Wenn das Problem weiterhin besteht, könnte der Listener kontinuierlich im folgenden Muster schleifen:

  • Dequeues der Nachricht
  • Instanziiert das Objekt
  • Leidet an einem Rollback
  • Legt die Nachricht oben in der Warteschlange zurück.

Der Warteschlangenkomponentendienst behandelt diesen Fehler mithilfe einer Reihe von anwendungsspezifischen Wiederholungswarteschlangen. Erstellt, wenn die Komponente installiert ist, gibt es sieben Warteschlangen für jede Anwendung, wie folgt:

  1. Die normale Eingabewarteschlange. Der Name dieser Warteschlange ist der COM+-Anwendungsname. Dies ist eine öffentliche Nachrichtenwarteschlange.

  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 zur Rückseite der zweiten Wiederholungswarteschlange verschoben werden. Diese Warteschlange heißt ApplicationName_0. Diese Warteschlange ist eine private Nachrichten 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 ausgeführt werden, bevor sie zur Rückseite der dritten Wiederholungswarteschlange verschoben wird. Diese Warteschlange ist "ApplicationName_1" genannt. Diese Warteschlange ist eine private Nachrichten 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 ausgeführt werden, bevor Sie zur Rückseite der vierten Wiederholungswarteschlange verschoben werden. Diese Warteschlange ist "ApplicationName_2" genannt. Diese Warteschlange ist eine private Nachrichten 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 ausgeführt werden, bevor sie in die fünfte Wiederholungswarteschlange verschoben werden. Diese Warteschlange ist "ApplicationName_3" genannt. Diese Warteschlange ist eine private Nachrichten 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 sechste Minuten verarbeitet. Eine Nachricht kann dreimal in dieser Warteschlange ausgeführt werden, bevor sie in die letzte Restwarteschlange verschoben werden. Diese Warteschlange ist "ApplicationName_4" genannt. Dies ist eine private Nachrichten queuing-Warteschlange.

  7. Eine anwendungsspezifische endende Restwarteschlange. Nachrichten werden hier verschoben, wenn die Transaktion wiederholt abbricht, wenn sie versucht hat, in der fünften Wiederholungswarteschlange zu versuchen. Diese Warteschlange ist "ApplicationName_DeadQueue". Dies ist eine private Nachrichten queuing-Warteschlange. Die letzte restende Warteschlange wird nicht von einem Warteschlangenlistener unterstützt. Nachrichten bleiben hier, bis sie manuell verschoben werden (vielleicht durch das Warteschlangen-Komponenten-Nachrichten-Mover-Hilfsprogramm) oder vom Message Queuing-Explorer gelöscht werden.

Nachrichten, die nicht wiedergegeben werden können, da es klar ist, dass jeder Wiederholungsversuch fehlschlägt, kann direkt in die anwendungsspezifische endende Restwarteschlange verschoben werden, ohne durch alle Wiederholungsstufen erweitert zu werden.

Der Spieler stellt ein COM+-Ereignis dar, um interessierten Parteien mitzuteilen, dass Nachrichten nicht wiedergegeben werden können. COM+-Ereignisse werden in den folgenden Situationen ausgestellt:

  • Wenn eine Transaktion abbricht
  • Wenn eine Nachricht von einer Warteschlange in eine andere verschoben wird
  • Wenn eine Nachricht auf die letzte restende Warteschlange abgelegt wird

Nachrichten können geändert werden, bevor Sie von einer Warteschlange zu einer anderen wechseln. Mit dem COM+-Warteschlangen-Komponentensicherheitsmechanismus kann eine Nachricht verschoben werden, um Warteschlangen erneut zu wiederholen und dann in die anfängliche Eingabewarteschlange der Anwendung einzufügen. Weitere Informationen zur Sicherheit von Warteschlangenkomponenten finden Sie unter "Sicherheitssicherheit in der Warteschlange".

Wiederholungswarteschlangen werden zusammen mit der Hauptanwendungswarteschlange erstellt, wenn die Anwendung entweder durch das Komponentendienste-Verwaltungstool oder mithilfe der COM+ Administrative SDK-Funktionen als Warteschlange gekennzeichnet ist. Der Warteschlangenkomponentendienst ermöglicht die Flexibilität im Wiederholungsmechanismus, indem die Wiederholungswarteschlangen gelöscht werden können. Wenn beispielsweise alle Wiederholungswarteschlangen gelöscht werden, wird eine Nachricht, die beständig abbricht, direkt aus der Anwendungswarteschlange in die anwendungsspezifische endende Warteschlange verschoben. Durch Entfernen einer oder mehrerer der Wiederholungswarteschlangen kann die Anzahl und Länge der Wiederholungsversuche reduziert werden. Wenn Warteschlangen aus der Wiederholungssequenz entfernt werden, entspricht die Zeitdauer der verbleibenden Warteschlangen der Position in der Sequenz der Wiederholungswarteschlangen. Wenn Sie beispielsweise die Warteschlange ApplicationName_1, ApplicationName_2 und ApplicationName_3 entfernen, werden die Nachrichten auf ApplicationName_4 verarbeitet, wie wenn die Warteschlange die zweite Wiederholungswarteschlange war.

Der Wiederholungsmechanismus ist so konzipiert, dass eine Nachricht abgeschlossen wird, falls möglich. In einigen Fällen ist es möglicherweise nicht möglich, dass die Nachricht erfolgreich ist. Ein Kunde kann beispielsweise versuchen, Geld aus einem Konto zu ziehen, das nicht genügend Geld hat. Unter diesen Umständen können Sie den Fehler auf mehrere Arten behandeln, einschließlich der folgenden:

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

Wie clientseitige persistente Fehler ermöglicht der Warteschlangenkomponentendienst eine Ausnahmeklasse, die einer Komponente zugeordnet werden kann. Die Ausnahmeklasse ist der Komponente mit der Registerkarte " Erweitert" auf der Seite "Komponentendiensteverwaltung" oder mithilfe der COM+ Administrativen Funktionen zugeordnet. Die Ausnahmeklasse ermöglicht es dem Entwickler, die Kontrolle zu haben, nachdem eine Nachricht erneut ausgeführt wurde und bevor diese Nachricht in die anwendungsspezifische endende Restwarteschlange verschoben wird. Weitere Informationen zur Ausnahmeklasse finden Sie unter "Persistent Client-Side Fehler".

Nachfolgend finden Sie die Sequenz von Ereignissen für die serverseitige Ausnahmebehandlung:

  1. Die Nachricht wird durch die verfügbaren anwendungsspezifischen Wiederholungswarteschlangen verschoben.
  2. Die letzte Wiederholung der letzten Wiederholungswarteschlange schlägt fehl.
  3. Der Warteschlangenkomponentendienst ruft die Zielkomponente aus der Nachricht ab und sucht nach einer Ausnahmeklasse.
  4. Die Laufzeit instanziiert die Ausnahmeklasse.
  5. Die Laufzeitabfragen IPlaybackControl auf der Ausnahmeklasse.
  6. Die Laufzeit ruft IPlaybackControl::FinalServerRetry in der Ausnahmeklasse auf.
  7. Die Laufzeit spielt alle Eigenschaften- und Methodenaufrufe aus der Nachricht in die Ausnahmeklasse zurück.
  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 Sie müssen eine Giftnachricht aus der endgültigen Restwarteschlange verschieben, verwenden Sie das Hilfsprogramm "Nachrichten-Mover". Weitere Informationen zum Nachrichten-Mover-Hilfsprogramm finden Sie unter Behandeln von Fehlern.

Clientseitige Fehler

Dauerhafte Client-Side Fehler