Wie können wir beheben zeitweise "Eine vorhandene Verbindung wurde zwangsweise geschlossen" Fehler durch eine Cisco CSS
Wir haben die "standard" drei-tier-Architektur mit unserer mittleren Schicht, die in IIS gehostet und der Zugriff via .net remoting. Diese Fehler auftreten zwischen unseren web-und web-services-Server (front-tier), die Remote verwaltet werden, um die app-Server (middle tier). Wir bekommen dieses Fehler 3-10 mal am Tag aus ~130K insgesamt Anrufe am Tag.
Die Ausnahme und die stapelablaufverfolgung immer so ähnlich Aussehen:
Exception Type: System.Net.WebException
Message: The underlying connection was closed: An unexpected error occurred on a receive.
Server stack trace:
at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessResponseException(WebException webException, HttpWebResponse& response)
at System.Runtime.Remoting.Channels.Http.HttpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at XXXXX.BusinessFacade.Interface.XXXXInterface.SubmitXXXX(
at XXX.XXXXWebServicesLibrary.XXXXService.CreateXXXXXX.RunXXXXMethod()
at XXX.XXXXWebServicesLibrary.XXXXService.XXXXXXMethod`2.RunMethod()
at XXX.XXXXWebServicesLibrary.XXXXXWebMethod`2.Run()HandleReturnMessage()
Inner Exception:
Exception Type: System.IO.IOException
Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
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)Read()
Inner Exception:
Exception Type: System.Net.Sockets.SocketException
Message: 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)Receive()
Gibt es keine besonderen remoting-Aufruf, verursacht dies geschehen, kann eine beliebige von Ihnen, die scheint, um auszuschließen, jede Art von Anwendung spezifische Ursache. Der einzige gemeinsame Nenner ist die "Exception Type: System.Net.Sockets.SocketException Message: Eine bestehende Verbindung zwangsweise geschlossen durch remote-host" - Teil der Fehler.
Den vorderen und mittleren Reihen sind durch eine firewall voneinander getrennt und wir sind auch unter Verwendung von VIP-Gerät. Ich vermute stark ein Problem mit unserem Netzwerk - /firewall-Konfiguration, aber unsere Netzwerk-Jungs sind nur kratzen Ihre Köpfe, und nicht mit Anregungen.
Obwohl 0.003% Ausfallrate unbedeutend erscheinen mögen, wir haben Partner, die Sie hinterfragen unsere Kommunikation sehr sorgfältig, und ich bin nur darauf warten, für diese zum Problem werden Sie es bemerken. Ich will nicht sagen zu müssen "ich weiß nicht", wenn die Zeit kommt.
Hat jemand irgendwelche Ideen auf, wie ich konnte mehr Informationen oder Vorschläge, die ich machen könnte, um unsere Netzwerk-Jungs Holen Sie sich dieses gelöst?
- Ist der appdomain, in der IIS-recycling, wenn die Ausnahme Auftritt?
- Wie könnte ich das sagen?
- Der IIS-Arbeitsprozess kann recyceln, die für einige Grund : Lebensdauer erreicht (in Minuten), Anzahl der Anfragen erreicht, Speicherlimit erreicht . Dies ist für "normale" reclycling je nach IIS -pool - Konfiguration. Wenn es recyceln, um eine abnormale Grund sollten Sie haben einen event-log wie : System - >W3SVC|Warnung:Ein Prozess für Anwendungspool 'xxx' erlitt einen tödlichen Kommunikation ... Für IIS 7 die Quelle ist 'WAR' nicht 'W3SVC'.
- Ich überprüfte die Protokolle, und ich bin nicht zu sehen, etwas, wie, dass.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Das problem war die Cisco CSS. Wir bestimmen diese, indem Sie die tier-1-Server direkt an die tier-2-Server und geht 48 Stunden ohne Beobachtung das problem. Einmal haben wir festgestellt, es war das CSS, das wir behoben dieses problem durch Anpassung der wahnsinnig niedrige Standardwert für diesen parameter:
"Standard-flow Inaktivitäts-timeouts in Sekunden für die TCP-oder UDP-port. Wenn eine Strömung ist im Leerlauf für die angegebene Zeitdauer in der timeout-Wert, der CSS reißt die Strömung und nimmt den flow-Ressourcen".
Setzen wir diese um 84 (84 16-Sekunden-Schritten). Da die Standard-keep-alive für HTTP ist 120 Sekunden, der Standardwert zu niedrig war.
Überprüfen recycling der Application-pool gehen, um Ihre IIS, und öffnen Sie die Eigenschaften der Application-Pool, auf dem Ihre remoting-Dienst ausgeführt wird.
Sie können konfigurieren, dass das recycling der Application-pools mit einem Zeit-Intervall, Anzahl der Anfragen oder definieren bestimmte Zeiten.
Könnte man die Abschaffung der recycling-Regeln und setzen Sie ein recycling zu einer Zeit, wo es keine verbindungen zu erwarten sind, wie 3.00 in der Nacht. Dann sehen, ob die Ausnahmen stil auftreten.
Könnte es sein eine Netzwerk-Komponente verursacht dieses. Der Weg, um dies auszuschließen wäre, beide Maschinen (oder test-Maschinen) auf dem gleichen Subnetz, dann führen Sie ein Last-test, und stellen Sie sicher, dass Sie nicht die gleichen Fehler.
Andere Dinge, die verursachen könnten, könnte es sein: