Problembehandlung bei Nachrichten in der Warteschlange

Dieser Abschnitt enthält allgemeine Fragen und Hilfe zur Problembehandlung für die Verwendung von Warteschlangen in Windows Communication Foundation (WCF).

Häufig gestellte Fragen

F: Ich habe WCF Beta 1 verwendet und den MSMQ-Hotfix installiert. Muss ich den Hotfix entfernen?

A: Ja. Dieser Hotfix wird nicht mehr unterstützt. WCF funktioniert jetzt auf MSMQ ohne Hotfixanforderung.

F: Es gibt zwei Bindungen für MSMQ: NetMsmqBinding und MsmqIntegrationBinding. Was sollte ich verwenden und wann?

A: Verwenden Sie NetMsmqBinding als Transport für die Kommunikation in der Warteschlange zwischen zwei WCF-Anwendungen. Verwenden Sie MsmqIntegrationBinding, um vorhandene MSMQ-Anwendungen zum Kommunizieren mit neuen WCF-Anwendungen zu nutzen.

F: Muss ich MSMQ aktualisieren, um die NetMsmqBindingMsmqIntegration Bindungen zu verwenden?

A: Nein. Beide Bindungen funktionieren mit MSMQ 3.0 unter Windows XP und Windows Server 2003. Bestimmte Features der Bindungen werden verfügbar, wenn Sie ein Upgrade auf MSMQ 4.0 in Windows Vista durchführen.

F: Welche Features der NetMsmqBinding und MsmqIntegrationBinding Bindungen sind in MSMQ 4.0, aber nicht in MSMQ 3.0 verfügbar?

A: Die folgenden Features sind in MSMQ 4.0, aber nicht in MSMQ 3.0 verfügbar:

• Benutzerdefinierte Nachrichtentod-Warteschlange wird nur für MSMQ 4.0 unterstützt.

• MSMQ 3.0 und 4.0 behandeln Giftnachrichten unterschiedlich.

• Nur MSMQ 4.0 unterstützt remote durchgeführtes Lesen.

F: Kann ich MSMQ 3.0 auf einer Seite einer in die Warteschlange eingereihten Kommunikation und MSMQ 4.0 auf der anderen Seite verwenden?

A: Ja.

F: Ich möchte vorhandene MSMQ-Anwendungen in neue WCF-Clients oder -Server integrieren. Muss ich beide Seiten meiner MSMQ-Infrastruktur aktualisieren?

A: Nein. Sie müssen auf beiden Seiten kein Upgrade auf MSMQ 4.0 durchführen.

Problembehandlung

Dieser Abschnitt enthält Antworten auf die häufigsten Problembehandlungsprobleme. Einige Probleme, die bekannte Einschränkungen sind, werden auch in den Versionshinweisen beschrieben.

F: Ich versuche, eine private Warteschlange zu verwenden, und ich erhalte die folgende Ausnahme: System.InvalidOperationException: Die URL ist ungültig. Die URL für die Warteschlange darf das Zeichen '$' nicht enthalten. Verwenden Sie die Syntax in net.msmq://machine/private/queueName, um eine private Warteschlange zu adressieren.

A: Überprüfen Sie den URI (Uniform Resource Identifier) der Warteschlange in Ihrer Konfiguration und Ihrem Code. Verwenden Sie nicht das Zeichen "$" im URI. Um beispielsweise eine private Warteschlange namens OrdersQueue zu adressieren, geben Sie den URI als net.msmq://localhost/private/ordersQueuean.

F: Das Aufrufen ServiceHost.Open() meiner in die Warteschlange eingereihten Anwendung löst die folgende Ausnahme aus: System.ArgumentException Eine Basisadresse darf keine URI-Abfragezeichenfolge enthalten. Why?

A: Überprüfen Sie den Warteschlangen-URI in der Konfigurationsdatei und im Code. Während MSMQ-Warteschlangen die Verwendung des Zeichens "?" unterstützen, interpretieren URIs dieses Zeichen als Anfang einer Zeichenfolgenabfrage. Um dieses Problem zu vermeiden, verwenden Sie Warteschlangennamen, die keine "?"-Zeichen enthalten.

F: Mein Sendevorgang war erfolgreich, aber es wird keine Dienstoperation beim Empfänger aufgerufen. Why?

A: Um die Antwort zu ermitteln, gehen Sie die folgende Checkliste durch:

• Überprüfen Sie, ob die Transaktionswarteschlangenanforderungen mit den angegebenen Zusicherungen kompatibel sind. Beachten Sie die folgenden Prinzipien:

  • Nur an eine Transaktionswarteschlange können Sie dauerhafte Nachrichten (Datagramme und Sitzungen) mit „genau einmal“-Zusicherungen (ExactlyOnce = true) senden.

  • Sie können Sitzungen nur mit "genau einmal"-Zusicherungen senden.

  • Eine Transaktion ist erforderlich, um Nachrichten in einer Sitzung aus einer Transaktionswarteschlange zu empfangen.

  • Sie können veränderliche oder dauerhafte Nachrichten (nur Datagramme) ohne Zusicherungen (ExactlyOnce = false) nur an eine nicht transaktionsbezogene Warteschlange senden oder empfangen.

• Überprüfen Sie die Dead-Letter-Queue. Wenn Sie die Nachrichten dort finden, bestimmen Sie, warum sie nicht zugestellt wurden.

• Überprüfen Sie die ausgehenden Warteschlangen auf Konnektivitäts- oder Adressierungsprobleme.

F: Ich habe eine benutzerdefinierte Warteschlange für inaktive Buchstaben angegeben, aber wenn ich die Absenderanwendung starte, erhalte ich eine Ausnahme, dass entweder die Warteschlange für inaktive Buchstaben nicht gefunden wird, oder die sendende Anwendung hat keine Berechtigung für die Warteschlange mit inaktiven Buchstaben. Wie kommt das?

A: Der benutzerdefinierte URI für die Dead-Letter-Queue muss "localhost" oder den Computernamen im ersten Segment enthalten, z. B.: net.msmq://localhost/private/myAppdead-letter queue.

F: Ist es immer erforderlich, eine benutzerdefinierte Dead-Letter Queue zu definieren, oder gibt es eine standardmäßige Dead-Letter Queue?

A: Wenn Zusicherungen "genau einmal" (ExactlyOnce = true) sind und wenn Sie keine benutzerdefinierte Dead-Letter-Warteschlange angeben, ist die Standardeinstellung eine systemweite transaktionsgebundene Dead-Letter-Warteschlange.

Wenn keine Zusicherungen vorhanden sindExactlyOnce = false, ist die Standardeinstellung keine Funktionalität für die Dead-Letter-Queue.

F: Mein Dienst löst "SvcHost.Open" mit der Meldung "EndpointListener-Anforderungen können nicht von der ListenerFactory erfüllt werden". Why?

A. Überprüfen Sie Ihren Servicevertrag. Möglicherweise haben Sie vergessen, "IsOneWay=true" auf alle Dienstvorgänge zu setzen. Warteschlangen unterstützen nur einseitige Dienstoperationen.

F: Es gibt Nachrichten in der Warteschlange, aber es wird kein Dienstvorgang aufgerufen. Was ist das Problem?

A: Ermitteln Sie, ob Ihr Diensthost im Fehlerzustand ist. Sie können dies überprüfen, indem Sie die Ablaufverfolgung ansehen oder IErrorHandler implementieren. Diensthostfehler, standardmäßig, wenn eine Giftnachricht erkannt wird.

F: Es gibt Nachrichten in der Warteschlange, aber mein warteschlangenbasierter, im Web gehosteter Dienst wird nicht aktiviert. Why?

Ein: Der häufigste Grund sind Berechtigungen.

1. Stellen Sie sicher, dass der NetMsmqActivator Prozess ausgeführt wird und dass die Identität des NetMsmqActivator Prozesses über Lese- und Suchberechtigung auf die Warteschlange verfügt.

2. Wenn NetMsmqActivator Warteschlangen auf einem Remotecomputer überwacht, stellen Sie sicher, dass NetMsmqActivator nicht unter einem eingeschränkten Token ausgeführt wird. So führen Sie das NetMsmqActivator mit einem uneingeschränkten Token aus.

   sc sidtype NetMsmqActivator unrestricted
   

Für nicht sicherheitsrelevante Webhosting-Probleme siehe: Webhosting einer in die Warteschlange eingereihten Anwendung.

F: Was ist die einfachste Möglichkeit, auf Sitzungen zuzugreifen?

A: Legen Sie AutoComplete=true für den Vorgang fest, der die letzte Nachricht in der Sitzung betrifft, und legen Sie AutoComplete=false für alle verbleibenden Dienstvorgänge fest.

F: Warum löst mein Dienst einen ProtocolException aus, wenn er aus einer Warteschlange liest, die sowohl Sitzungsnachrichten als auch Datagrammnachrichten enthält?

A: Es gibt einen grundlegenden Unterschied in der Art und Weise, wie wartende Sitzungsnachrichten und wartende Datagrammnachrichten zusammengesetzt werden. Aus diesem Grund kann ein Dienst, der erwartet, eine eingereihte Sitzungsnachricht zu lesen, keine eingereihte Datagrammnachricht empfangen, und ein Dienst, der erwartet, eine eingereihte Datagrammnachricht zu lesen, kann keine Sitzungsnachricht empfangen. Beim Versuch, beide Arten von Nachrichten aus derselben Warteschlange zu lesen, wird die folgende Ausnahme ausgelöst:

System.ServiceModel.MsmqPoisonMessageException: The transport channel detected a poison message. This occurred because the message exceeded the maximum number of delivery attempts or because the channel detected a fundamental problem with the message. The inner exception may contain additional information.
---> System.ServiceModel.ProtocolException: An incoming MSMQ message contained invalid or unexpected .NET Message Framing information in its body. The message cannot be received. Ensure that the sender is using a compatible service contract with a matching SessionMode.

Die System-Dead-Letter-Warteschlange sowie jede benutzerdefinierte Dead-Letter-Warteschlange ist besonders anfällig für dieses Problem, wenn eine Anwendung sowohl Sitzungsnachrichten in der Warteschlange als auch Datagrammnachrichten in der Warteschlange vom selben Computer sendet. Wenn eine Nachricht nicht erfolgreich gesendet werden kann, wird sie in die Tote-Brief-Warteschlange verschoben. Unter diesen Umständen ist es möglich, sowohl Sitzungs- als auch Datagram-Nachrichten in der Dead-Letter Queue zu haben. Es gibt keine Möglichkeit, beide Arten von Nachrichten während der Laufzeit beim Lesen aus einer Warteschlange zu unterscheiden. Daher sollten Anwendungen nicht sowohl Warteschlangen-Sitzungsnachrichten als auch Warteschlangen-Datagrammnachrichten von demselben Computer senden.

MSMQ-Integration: Spezifische Problembehandlung

F: Wenn ich eine Nachricht sende oder wenn ich den Diensthost öffne, erhalte ich eine Fehlermeldung, die angibt, dass das Schema falsch ist. Why?

A: Wenn Sie die MSMQ-Integrationsbindung verwenden, müssen Sie das Schema "msmq.formatname" verwenden. Beispiel: msmq.formatname:DIRECT=OS:.\private$\OrdersQueue. Wenn Sie jedoch die benutzerdefinierte Dead-Letter-Queue angeben, müssen Sie das net.msmq-Schema verwenden.

F: Wenn ich einen öffentlichen oder privaten Formatnamen verwende und den Diensthost unter Windows Vista öffnen, erhalte ich eine Fehlermeldung. Why?

Ein: Der WCF-Integrationskanal unter Windows Vista überprüft, ob eine Unterabfrage für die Hauptanwendungswarteschlange zum Behandeln von Giftnachrichten geöffnet werden kann. Der Subqueue-Name wird von einem msmq.formatname-URI abgeleitet, der an den Listener übergeben wird. Der Unterqueue-Name in MSMQ kann nur ein direkter Formatname sein. Also sehen Sie den Fehler. Ändern Sie die URI der Warteschlange in einen direkten Formatnamen.

F: Wenn eine Nachricht von einer MSMQ-Anwendung empfangen wird, befindet sich die Nachricht in der Warteschlange und wird nicht von der empfangenden WCF-Anwendung gelesen. Why?

A: Überprüfen Sie, ob die Nachricht einen Textkörper hat. Wenn die Nachricht keinen Text enthält, ignoriert der MSMQ-Integrationskanal die Nachricht. Implementieren Sie IErrorHandler, um über Ausnahmen benachrichtigt zu werden und die Ablaufverfolgungen zu prüfen.

Sicherheitsbezogene Problembehandlung

F: Wenn ich das Beispiel ausführt, das eine Standardbindung im Arbeitsgruppenmodus verwendet, scheinen Nachrichten gesendet zu werden, werden aber nie vom Empfänger empfangen.

A: Standardmäßig werden Nachrichten mit einem internen MSMQ-Zertifikat signiert, das den Active Directory-Verzeichnisdienst benötigt. Da Active Directory nicht verfügbar ist, schlägt das Signieren der Nachricht im Arbeitsgruppenmodus fehl. Daher wird die Nachricht in der Dead-Letter-Queue landen, und die Fehlerursache, z. B. "Ungültige Signatur", wird angegeben.

Die Problemumgehung besteht darin, die Sicherheit zu deaktivieren. Um den Arbeitsgruppenmodus zu aktivieren, setzen Sie Mode = None.

Eine weitere Problemumgehung besteht darin, MsmqTransportSecurity von der Transport-Eigenschaft abzurufen und sie auf Certificate zu setzen und das Clientzertifikat festzulegen.

Eine weitere Problemumgehung besteht darin, MSMQ mit Active Directory-Integration zu installieren.

F: Wenn ich eine Nachricht mit standardmäßiger Bindung (Transportsicherheit aktiviert) in Active Directory an eine Warteschlange sende, erhalte ich eine Meldung "internes Zertifikat wurde nicht gefunden". Wie kann ich dies korrigieren?

A: Dies bedeutet, dass das in Active Directory befindliche Zertifikat des Absenders erneuert werden muss. Öffnen Sie dazu die Systemsteuerung, die Verwaltungstools, die Computerverwaltung, klicken Sie mit der rechten Maustaste auf MSMQ, und wählen Sie "Eigenschaften" aus. Wählen Sie die Registerkarte "Benutzerzertifikat " aus, und klicken Sie auf die Schaltfläche " Verlängern ".

F: Wenn ich eine Nachricht mithilfe von Certificate sende und das zu verwendende Zertifikat angebe, erhalte ich die Meldung "Ungültiges Zertifikat". Wie kann ich dies korrigieren?

A: Sie können keinen lokalen Computerzertifikatspeicher mit dem Zertifikatsmodus verwenden. Sie müssen das Zertifikat aus dem Zertifikatspeicher des Computers mithilfe des Zertifikat-Snap-Ins in den aktuellen Benutzerspeicher kopieren. So rufen Sie das Zertifikat-Snap-In ab:

1. Klicken Sie auf "Start", wählen Sie "Ausführen" aus, geben Sie mmc"OK" ein, und klicken Sie auf "OK".

2. Öffnen Sie in der Microsoft Management Console das Menü "Datei ", und wählen Sie "Snap-In hinzufügen/entfernen" aus.

3. Klicken Sie im Dialogfeld "Snap-In hinzufügen/entfernen " auf die Schaltfläche "Hinzufügen ".

4. Wählen Sie im Dialogfeld "Eigenständiges Snap-In hinzufügen " die Option "Zertifikate" aus, und klicken Sie auf "Hinzufügen".

5. Wählen Sie im Dialogfeld Zertifikat-Snap-In "Mein Benutzerkonto" aus, und klicken Sie auf "Fertig stellen".

6. Fügen Sie als Nächstes ein zweites Zertifikat-Snap-In mithilfe der vorherigen Schritte hinzu, wählen Sie jedoch dieses Mal "Computerkonto " aus, und klicken Sie auf "Weiter".

7. Wählen Sie "Lokaler Computer " aus, und klicken Sie auf "Fertig stellen". Sie können zertifikate jetzt aus dem Zertifikatspeicher des Computers in den aktuellen Benutzerspeicher ziehen und ablegen.

F: Wenn mein Dienst aus einer Warteschlange auf einem anderen Computer im Arbeitsgruppenmodus liest, erhalte ich eine Ausnahme "Zugriff verweigert".

A: Im Arbeitsgruppenmodus muss eine Remoteanwendung die Berechtigung zum Zugriff auf die Warteschlange haben, um auf die Warteschlange zugreifen zu können. Fügen Sie "Anonyme Anmeldung" zur Zugriffssteuerungsliste (Access Control List, ACL) der Warteschlange hinzu und erteilen Sie ihr Leseberechtigung.

F: Wenn ein Netzwerkdienstclient (oder ein Client, der nicht über ein Domänenkonto verfügt) eine in die Warteschlange eingereihte Nachricht sendet, schlägt die Übermittlung mit einem ungültigen Zertifikat fehl. Wie kann ich dies korrigieren?

A: Überprüfen Sie die Bindungskonfiguration. Die Standardbindung hat MSMQ-Transportsicherheit aktiviert, um die Nachricht zu signieren. Deaktivieren Sie sie.

Remote-Transaktionen empfangen

F: Wenn ich eine Warteschlange auf Computer A und einen WCF-Dienst habe, der Nachrichten aus einer Warteschlange auf Computer B liest (das Szenario für remote transacted receive), werden Nachrichten nicht aus der Warteschlange gelesen. Die Ablaufverfolgungsinformationen deuten darauf hin, dass der Empfang mit der Meldung "Transaktion kann nicht importiert werden" fehlgeschlagen ist. Was kann ich tun, um dies zu beheben?

A: Hierfür gibt es drei mögliche Gründe:

• Wenn Sie sich im Domänenmodus befinden, erfordert der Empfang von Remote-Transaktionen den Netzwerkzugriff des Microsoft Distributed Transaction Coordinator (MSDTC). Sie können dies mit "Komponenten hinzufügen/entfernen" aktivieren.

  

• Überprüfen Sie den Authentifizierungsmodus für die Kommunikation mit dem Transaktions-Manager. Wenn Sie sich im Arbeitsgruppenmodus befinden, muss "Keine Authentifizierung erforderlich" ausgewählt werden. Wenn Sie sich im Domänenmodus befinden, muss "Gegenseitige Authentifizierung erforderlich" ausgewählt werden.

  

• Stellen Sie sicher, dass MSDTC in der Liste der Ausnahmen in den Einstellungen der Internetverbindungsfirewall enthalten ist.

• Stellen Sie sicher, dass Sie Windows Vista verwenden. MSMQ unter Windows Vista unterstützt remote durchgeführtes Lesen. MSMQ unter früheren Windows-Versionen unterstützt keine remote durchgeführte Lesevorgänge.

F: Warum erhalte ich eine Ausnahme wegen Zugriffsverweigerung, wenn der Dienst, der aus der Warteschlange liest, ein Netzwerkdienst ist, beispielsweise in einem Webhost?

Ein: Der Lesezugriff des Netzwerkdiensts muss der Warteschlangen-ACL hinzugefügt werden, um sicherzustellen, dass ein Netzwerkdienst aus der Warteschlange lesen kann.

F: Kann ich den MSMQ-Aktivierungsdienst verwenden, um Anwendungen basierend auf Nachrichten in einer Warteschlange auf einem Remotecomputer zu aktivieren?

A: Ja. Dazu müssen Sie den MSMQ-Aktivierungsdienst so konfigurieren, dass er als Netzwerkdienst ausgeführt wird, und den Netzwerkdienstzugriff auf die Warteschlange auf dem Remotecomputer hinzufügen.

Verwenden von benutzerdefinierten MSMQ-Bindungen mit aktivierter ReceiveContext-Funktion

Bei Verwendung einer benutzerdefinierten MSMQ-Bindung mit ReceiveContext aktiviert, verwendet die Verarbeitung einer eingehenden Nachricht einen Thread aus dem Threadpool, da der native MSMQ den Abschluss von E/A für asynchrone ReceiveContext Empfangsvorgänge nicht unterstützt. Dies liegt daran, dass die Verarbeitung einer solchen Nachricht interne Transaktionen für ReceiveContext nutzt und dass MSMQ keine asynchrone Verarbeitung unterstützt. Um dieses Problem zu umgehen, können Sie dem Endpunkt einen SynchronousReceiveBehavior hinzufügen, um die synchrone Verarbeitung zu erzwingen oder auf 1 festzulegen MaxPendingReceives .