web-dev-qa-db-de.com

Eine bestehende Verbindung wurde vom Remote-Host-WCF zwangsweise geschlossen

Ich habe einen WCF-Webservice, der einwandfrei funktioniert. Es gibt jedoch einen bestimmten Anruf, der fehlschlägt - jedoch nur für bestimmte Benutzer. Der Aufruf ist ziemlich einfach - es ist ein Aufruf, um eine Liste von Personenobjekten abzurufen. 

Für Benutzer A funktioniert es gut. Der Dienst fragt die Datenbank ab, erstellt die Liste der Personenobjekte und gibt sie an die aufrufende Anwendung zurück. 

Für Benutzer B schlägt dies fehl. Das Seltsame ist, dass der Service beim Debuggen gut zu funktionieren scheint. Es kann die Datenbank abfragen, erstellt das List-Objekt und gibt es zurück. Der Dienst selbst fällt nie aus. Die Clientanwendung erhält jedoch den Fehler "Eine bestehende Verbindung wurde vom Remote-Host zwangsweise geschlossen". 

Mir scheint, dass etwas passiert, wenn die Service-Schicht versucht, die Daten im XML-Format zu verpacken, um sie an die aufrufende Anwendung zurückzusenden. Ich denke, dass es ein datenbezogenes Problem sein muss, weil der Anruf für andere Benutzer gut funktioniert. Ich habe mir die Daten visuell angesehen und merke nichts Seltsames. Eine Vermutung ist, dass die Daten für Benutzer B einige versteckte oder etwas versteckte Zeichen enthalten und daher dazu führen, dass der Dienst unerwartet geschlossen wird. Sowas in der Art.

Irgendwelche Ideen?

45
Corey Burnett

Das Beste, was ich für die Diagnose solcher Dinge gefunden habe, ist der Service Trace Viewer. Das Einrichten ist ziemlich einfach (vorausgesetzt, Sie können die Configs bearbeiten):

http://msdn.Microsoft.com/de-de/library/ms732023.aspx

Hoffe das hilft.

72
NateTheGreat

Ich hatte dieses Problem, da auf meiner Website kein Zertifikat an den SSL-Port gebunden war. Ich dachte, ich würde es erwähnen, weil ich diese Antwort nirgendwo im Google-Web gefunden habe und ich Stunden gebraucht habe, um es herauszufinden. In der Ereignisanzeige wurde nichts angezeigt, was für die Diagnose absolut fantastisch war. Hoffe, das erspart jemandem den Schmerz.

23
Neuralsim

Ich habe das einmal gesehen. Fordern die Benutzer unterschiedliche Datenmengen an? Ich habe festgestellt, dass selbst wenn Sie eine Bindung für Datennutzlasten konfigurieren können (d. H. maxReceivedMessageSize), die httpRuntimemaxRequestLength die WCF-Einstellung übertrumpft. Wenn also IIS versucht, eine Anforderung zu bedienen, die diese Anforderung überschreitet, zeigt es dieses Verhalten.

Stell es dir so vor:

Wenn maxReceivedMessageSize in Ihrem WCF-Verhalten 12 MB beträgt und maxRequestLength 4 MB (Standard) ist, gewinnt IIS.

11
kd7

Ich habe festgestellt, dass Sie diesen Fehler erhalten können, wenn das zurückgegebene Objekt nur Auto-Getter-Eigenschaften hat, die im Konstruktor (mit der C # 6.0-Syntax) initialisiert werden.

Ich glaube, das liegt daran, dass WCF Objekte auf der Clientseite deserialisiert, indem ein parameterloser Konstruktor verwendet wird und dann die Eigenschaften für das Objekt festgelegt werden. Es muss eine set available (es kann privat sein) vorhanden sein, um das Objekt zu füllen, andernfalls schlägt es fehl.

8
Philippe

Ich hatte gerade diesen Fehler jetzt nur auf dem Server und die Lösung bestand darin, ein maxItemsInObjectGraph-Attribut in wcf web.config Unter <behavior>-Tag festzulegen:

<dataContractSerializer maxItemsInObjectGraph="2147483646"/>
6
ParPar

Ich habe die gleiche Ausnahme gefunden und einen InnerException: SocketException. in der svclog-Ablaufverfolgung gefunden.

Nachdem ich im Windows-Ereignisprotokoll nachgesehen hatte, sah ich einen Fehler in der System.ServiceModel.Activation.TcpWorkerProcess-Klasse.

Hosten Sie Ihren wcf-Dienst in IIS mit netTcpBinding und Portfreigabe? 

Anscheinend gibt es einen Fehler in der Portfreigabefunktion von IIS. Überprüfen Sie das fix :

Meine Lösung ist, Ihren WCF-Dienst in einem Windows-Dienst zu hosten.

3
Anben PANGLOSE

Nachdem ich mir die Haare für ungefähr 6 Stunden dieses völlig nutzlosen Fehlers ausgezogen hatte, bestand mein Problem darin, dass mein data transfer objects zu komplex war. Beginnen Sie mit einfachen Eigenschaften wie public long Id { get; set;} das ist es ... nichts Besonderes.

3
Serj Sagan

Ich habe das gleiche Problem. Meine Lösung ist folgende:

Wenn Sie LinQ2SQL in Ihrem Projekt verwenden, öffnen Sie Ihre DB-Datei in Visual Studio und ändern Sie den Serialisierungsmodus auf "Unidirectional"

3
gürcan

In meinem Fall war es auch mit der Serialisierung. Ich muss hinzufügen [KnownType(typeof(...)] für alle Klassen, die bei der Serialisierung auftreten könnten.

2
Hans S

Das Problem hatte ich auch mit der Serialisierung. Die Ursache war, dass einige meiner DTO-/Geschäftsklassen und Eigenschaften umbenannt oder gelöscht wurden, ohne die Dienstreferenz zu aktualisieren. Ich bin überrascht, dass ich keinen contract filter mismatch error bekommen habe. Aber das Update des Dienstes ref hat den Fehler für mich behoben (derselbe Fehler wie bei OP). 

2
goku_da_master

Dieses Problem wurde beim Debuggen von einem Webprojekt an einen Webdienst in derselben Lösung ausgelöst. Der Webdienst gab Antworten zurück, die das Webprojekt nicht verstehen konnte. An einigen Stellen würde es wieder funktionieren, dann wieder aufhören. 

Dies war darauf zurückzuführen, dass zwischen diesen Projekten kein expliziter Verweis bestand. Daher wurde der Webdienst nicht erstellt, wenn mit F5 das Debuggen gestartet wurde. Nachdem ich das hinzugefügt hatte, gingen die Fehler weg.

0
StingyJack