Jak możemy rozwiązać przerywany „Istniejące połączenie zostało gwałtownie zamknięte” błędów powodowanych przez Cisco CSS

Question

Mamy „standard” architekturę trójwarstwowy z naszej środkowej warstwie obsługiwanej w IIS i dostępne za pośrednictwem usług zdalnych .net. Te błędy występują między naszymi serwerami usług WWW i usług internetowych (warstwa główna), które są zdalne dla serwerów aplikacji (warstwa środkowa). Otrzymamy ten błąd 3-10 razy dziennie po ~ 130 tys. Połączeń w ciągu dnia.

Wyjątkiem i stos ślad zawsze wyglądać podobnie do tego:

---

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() 

---

Nie ma szczególności wezwanie remoting że powoduje to się stało, może to być każdy z nich, który wydaje się wykluczać każda przyczyna specyficzna dla aplikacji. Jedynym wspólnym mianownikiem jest "Typ wyjątku: System.Net.Socket.SocketException Wiadomość: Istniejące połączenie zostało przymusowo zamknięte przez zdalny host" część błędu.

przednie i środkowe poziomy są rozdzielone przez zaporę i jesteśmy również z wykorzystaniem urządzenia VIP. Zdecydowanie podejrzewam, że problem dotyczy naszej konfiguracji sieci/zapory, ale nasi użytkownicy sieci tylko drapią się po głowie i nie oferują żadnych sugestii.

Chociaż wskaźnik niepowodzenia 0,003% może wydawać się nieistotny, mamy partnerów, którzy bardzo uważnie analizują naszą komunikację i czekam tylko na to, aby staną się problemem, który zauważają. Nie chcę mówić "nie wiem", kiedy nadejdzie ten czas.

Czy ktoś ma jakieś pomysły jak mogę podać więcej informacji lub jakiekolwiek sugestie mógłbym zrobić dla naszych chłopaków sieciowych, aby to rozwiązać?

Answer 1

problem był Cisco CSS. Ustaliliśmy to, wskazując serwery warstwy 1 bezpośrednio na serwery warstwy 2 i przez 48 godzin bez zaobserwowania problemu. Kiedy ustaliliśmy, że to CSS, poprawiliśmy ten problem, dostosowując szalenie niską domyślną wartość tego parametru:

"Domyślne limity czasu bezczynności w sekundach dla portu TCP lub UDP.Jeśli przepływ jest bezczynny przez czas określony w wartości limitu czasu, CSS odrywa przepływ i odzyskuje zasoby przepływu. "

Ustawiliśmy to na 84 (co daje 84 16-sekundowe przyrosty). domyślna wartość podtrzymania dla protokołu HTTP wynosi 120 sekund, wartość domyślna była zbyt niska.

Answer 2

Aby sprawdzić recyklingu puli aplikacji przejdź do IIS i otwórz właściwości puli aplikacji, na którym jest uruchomiona usługa usług zdalnych. Można skonfigurować recykling pul aplikacji przy użyciu interwału czasowego, liczby żądań lub określonych czasów.

Można usunąć obecne zasady recyklingu i recyklingu, aby ustawić czasie, gdy nie są spodziewane żadne połączenia, jak 3.00 w nocy. Następnie sprawdź, czy występują wyjątki.

Answer 3

Może to być składnik sieci powodujący to. Aby temu zaradzić, należy umieścić obie maszyny (lub maszyny testowe) w tej samej podsieci, a następnie uruchomić test obciążenia i sprawdzić, czy nie wystąpił ten sam błąd.

innych rzeczy, które mogłyby być przyczyną może być:

• przekroczenie limitu czasu, można zwiększyć limit czasu ceni
• zbyt duży rozmiar wiadomości, spróbuj zwiększyć rozmiar wiadomości dozwolone, także wielkość zamówienie dozwolone w IIS
• można być uderzenie jakąś wartość max, takie jak nazywa max lub połączenia max patrz: http://msdn.microsoft.com/en-us/library/ee377061(v=bts.10).aspx