Ich sehe ein Problem mit WCF, wenn ich die generierten Async-Methoden auf dem Client aufruft ... Wenn ich auf eine asynchrone Methode warte und anschließend eine nicht asynchrone Methode auf demselben Client aufruft, kehrt die Blockierungsmethode nie zurück .
Hier ist eine triviale Reproduktion des Problems:
%Vor%Nichts kompliziert hier. Ein einfacher WCF-Dienst (synchron implementiert), der eine einzelne Methode verfügbar macht.
%Vor% Bitte beachtet, das ist nicht der übliche Fall, dass jemand den Nachrichten-Thread blockiert oder vergisst, ConfigureAwait(false) aufzurufen. Dies ist eine Konsolenanwendung und das Hinzufügen von ConfigureAwait hat keine Auswirkungen auf das Verhalten.
Bizarr, was hilft, ist zu tun:
%Vor%vor dem erneuten Aufruf der synchronen WCF-Methode. So scheint es, dass WCF irgendwie thread-lokalen Kontext nach dem Wiederaufnehmen von einem asynchronen Methodenaufruf hinterlässt, der dann aufgeräumt wird.
Irgendeine Idee was könnte das verursachen? Der Aufruf-Stack aus dem Deadlock- / Non-Deadlock-Fall zeigt einige Unterschiede in der WCF-Client-Operation:
Guter Stapel:
%Vor%Schlechter Stapel:
%Vor% Es scheint, dass irgendwo in DuplexChannelBinder WCF davon ausgeht, dass ein anderer Thread Nachrichten vom Kanal liest, nachdem ein Async-Aufruf abgeschlossen wurde.
Irgendwelche Gedanken? Offensichtlich bin ich nicht begeistert von der Idee,% code_% Anweisungen% zu meinem Code hinzuzufügen ...
Prost, Markiere
Ich stieß auf ein ähnliches Problem, wenn ich denselben Client zum Aufruf mehrerer Operationen verwendete. Wenn dasselbe Objekt nicht gleichzeitig mehrere Methoden aufrufen kann, sieht es aus, als ob in der Prozedur der Methode wcf ein Locking implementiert wurde.
so, bis 1 Anruf nicht abgeschlossen ist, können Sie nicht erneut mit demselben Objekt den WCF-Dienst aufrufen.
Tags und Links wcf c# async-await asynchronous deadlock