web-dev-qa-db-de.com

Eine bestehende Verbindung wurde vom Remote-Host zwangsweise geschlossen

Ich habe einen dicken VB.NET Winform-Client, der den alten asmx-Webdienst verwendet. Wenn ich eine Abfrage ausführen, die eine Weile dauert oder eine große Menge von Daten an einen Web-Service in einem Dataset weitergibt, erhalte ich häufig den betreffenden Fehler.

Der Fehler scheint in <1 Minute aufzutreten. Dies ist weit weniger als der von mir eingestellte Webservice-Timeout-Wert oder der Timeout-Wert für das ADO Command-Objekt, das die Abfrage im Webserver ausführt.

Dies scheint immer dann der Fall zu sein, wenn ich eine große Abfrage durchführe, von der erwartet wird, dass viele Zeilen zurückgegeben werden, oder wenn ich eine große Datenmenge an den Webdienst sende. Zum Beispiel trat es gerade bei der Übergabe eines großen Datensatzes an den Webserver auf:

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote Host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote Host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
   --- End of inner exception stack trace ---
   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Smit.Pipeline.Bo.localhost.WsSR.SaveOptions(String emailId, DataSet dsNeighborhood, DataSet dsOption, DataSet dsTaskApplications, DataSet dsCcUsers, DataSet dsDistinctUsers, DataSet dsReferencedApplications) in C:\My\Code\Pipeline2\Smit.Pipeline.Bo\Web References\localhost\Reference.vb:line 944
   at Smit.Pipeline.Bo.Options.Save(TaskApplications updatedTaskApplications) in 

Ich habe eine Unmenge von Postings zu diesem Fehler gesucht und es ist überraschend, wie unterschiedlich die Umstände sind, die diesen Fehler verursachen. Ich habe mit Wireshark herumgespielt, aber ich weiß nicht, wie ich damit umgehen soll.

Diese Anwendung hat nur etwa 20 Benutzer gleichzeitig und ich bin in der Lage, diesen Fehler mitten in der Nacht zu reproduzieren, wenn wahrscheinlich niemand die App verwendet. Daher denke ich nicht, dass die Anzahl der Anfragen an den Webserver oder zu der Datenbank ist hoch. Ich bin wahrscheinlich die einzige Person, die die App gerade verwendet, und ich habe gerade den Fehler erhalten. Es scheint alles zu tun zu haben, wenn die Daten in beide Richtungen weitergegeben werden.

Dieser Fehler ist wirklich chronisch und bringt mich um. Bitte helfen.

9
ChadD

Überprüfen Sie die Bindungseinstellung app.config Ihres Clients und prüfen Sie, ob Sie eine maximale Nachrichtengröße angegeben haben. Der Standardwert hierfür ist 65536

Um dies zu ändern, fügen Sie es entweder in Ihre Bindungskonfiguration ein (maxReceivedMessageSize, maxBufferSize und maxArrayLength sind die Haupteigenschaften dafür) in Ihrer app.config oder programmgesteuert, indem Sie die Eigenschaft in der Bindung ändern

System.ServiceModel.BasicHttpBinding binding = new System.ServiceModel.BasicHttpBinding();

// if you are getting a LOT of data back, you will need to up Message Size
binding.MaxReceivedMessageSize = int.MaxValue; 

Wenn sich das Problem dadurch nicht beheben lässt, müssen Sie das Ereignisprotokoll der Serverseite auf Details überprüfen. Die Nachricht bedeutet, dass der Client nicht erwartet hat, dass die Verbindung geschlossen wird, aber dies tat es und es könnte viele verschiedene Dinge bedeuten.

Verwenden Sie nach Möglichkeit WCF für Webdienste. Es löst viele Probleme, unter denen die ASMX-Dienste immer noch leiden.

Verwenden Sie diese Option, um das serverseitige Übertragungslimit und das Ausführungszeitlimit zu erhöhen

<configuration>
  <system.web> 
    <httpRuntime maxMessageLength="409600" executionTimeoutInSeconds="300"/> 
  </system.web>
</configuration> 
2
Greg Olmstead

Ich hatte genau das gleiche Problem. Webdienstaufrufe schlagen mit derselben zeitweiligen Ausnahme (~ einmal täglich) fehl. Es war nicht mit zu großen Paketgrößen oder zu kleinen Timeouts verbunden.

Am Ende habe ich nur eine Wiederholungslogik eingefügt, die das Problem gelöst hat. Siehe: Wie kann ich dieses Wiederholungsszenario für Ausnahmen verbessern?

2
robbie

Dieser Code hat das Problem für mich gelöst:

Socket.ReceiveFrom(Buffer, Net.Sockets.SocketFlags.None, ReceiveEndpoint)
Socket.SendTo(Buffer, Length, Net.Sockets.SocketFlags.None, ReceiveEndpoint)

Bei Verwendung der Funktion mit socketsflags wurde der Server/Client nicht mehr getrennt.

In meinem Fall trat bei meinem generischen HTTP-Handler (handler.ashx) die unerwartet abgebrochene Verbindung auf, wenn versucht wurde, große Dateien von einem WCF-Dienst abzurufen. Am Ende kam die Antwort auf eine Microsoft-Webseite ( https://msdn.Microsoft.com/de-de/library/ms733742.aspx ) und ein Aufruf an Microsoft, der mir diesen kritischen Punkt mitteilte auf dieser Seite wurde falsch geschrieben (hätte statt "Streaming" "gestreamt" werden sollen). Das korrigierte Code-Snippet von dieser Seite, das auf die Datei app.config meines WCF-Diensts angewendet wird, lautet wie folgt:

<system.serviceModel>
<bindings>
    ...
    <basicHttpBinding>
    <binding name="ExampleBinding" transferMode="Streamed"/>
        </basicHttpBinding>
    </bindings>
    ...
<system.serviceModel>

Der Schlüssel war, den Übertragungsmodus einzustellen.

1

Wenn es sich um ASP.NET handelt, setzen Sie die maxRequestLength in der Datei web.config auf einen höheren Wert

<httpRuntime maxRequestLength="65536"/>

Erhöhen Sie den Wert nicht zu stark, da dies zu anderen Fehlern führen kann, wie z. B. Access Denial usw. Wenn es sich um eine Datenübertragung zu einem Remote-Server handelt, versuchen Sie, die Daten zu slicen und in Klumpen zu senden.

Mit freundlichen Grüßen,

Mafaz

1
sm2mafaz

Für IIS 7 (in meinem Fall) war die Anwendungspoolidentität des Webservice "ApplicationPoolIdentity". Ich habe einen lokalen Benutzer zugewiesen und es hat gut funktioniert. 

0
user007

Okay, ich habe den gleichen Fehler. In meinem Fall lag das Problem jedoch bei AV-Software, die die Berichterstellung lokal blockierte.

0
Andrew Kostenko

versuchen Sie dies, es funktioniert für mich für 10000 per Netzwerk-Stream gesendet 

definieren Sie SendBufferSize mehr als die Einstellung des aktuellen TcpClient oder optimieren Sie Ihr System . Wenn nicht definiert, ist der Wert 8192, was bedeutet, dass Sie kein Byte mehr senden können.

**YourInstantTcpClient**.SendBufferSize = 6550000 

Tut mir leid, ich bin ein thailändisches Volk, vielleicht ist mein Englisch nicht gut.

0
mezz