Comment pouvons-nous Résoudre les problèmes intermittents « Une connexion existante a été fermée de force » les erreurs causées par un Cisco CSS

Question

Nous avons trois architecture de niveau « standard » avec notre niveau intermédiaire hébergé dans IIS et accessible via .net Remoting. Ces erreurs se produisent entre nos services Web et Web (serveurs de niveau avant) qui sont Remoting aux serveurs d'applications (de niveau intermédiaire). Nous allons obtenir cette erreur 3-10 fois par jour sur le total des appels ~ 130K dans la journée.

Le regard trace d'exception et de la pile toujours semblable à ceci:

---

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

---

Il n'y a pas d'appel de Remoting particulier qui fait que cela se produise, il peut être l'un d'eux qui semble exclure toute sorte de cause spécifique d'application. Le seul dénominateur commun est le « Type d'exception: System.Net.Sockets.SocketException Message: Une connexion existante a été fermée de force par l'hôte distant ». Partie de l'erreur

L'avant et les niveaux intermédiaires sont séparés par un pare-feu et nous utilisons également un dispositif de VIP. Je soupçonne fortement un problème avec notre configuration réseau / pare-feu, mais nos gars de réseau sont qu'effleurer la tête et ne pas offrir des suggestions.

Bien que le taux d'échec de 0,003% peut sembler insignifiant, nous avons des partenaires qui scrutent très attentivement nos communications et j'attends juste que cela devienne un problème qu'ils remarquent. Je ne veux pas avoir à dire: « Je ne sais pas » le moment venu.

Est-ce que quelqu'un a des idées sur la façon dont je pourrais fournir plus d'informations ou des suggestions que je pourrais faire à nos gars de réseau pour régler cette question?

Answer 1

Le problème a été le Cisco CSS. Nous avons déterminé ce en pointant les serveurs de niveau 1 directement au niveau 2 serveurs et passer 48 heures sans observer le problème. Une fois que nous avons déterminé qu'il était le CSS, nous avons corrigé ce problème en ajustant la valeur par défaut faible pour ce insensément paramètre:

« inactivité du flux par défaut les délais d'attente, en secondes, pour le port TCP ou UDP. Si un flux est inactif pendant la durée spécifiée dans la valeur de délai d'attente, les larmes CSS vers le bas le flux et récupère les ressources de flux ».

Nous avons mis ceci à 84 (qui est de 84 16 secondes par incréments). Depuis le keep-alive par défaut pour HTTP est de 120 secondes, la valeur par défaut est trop faible.

Answer 2

Pour vérifier le recyclage du pool d'applications vers le IIS et ouvrez les propriétés de l'application Piscine sur lequel votre service d'accès distant est en cours d'exécution. Vous pouvez configurer le recyclage des pools d'applications en utilisant un intervalle de temps, le nombre de demandes ou de définir des moments précis.

Vous pouvez supprimer les règles de recyclage et définir un recyclage à un moment où aucune connexion ne devraient, comme 3,00 la nuit. Ensuite, voir si les exceptions Stil se produisent.

Answer 3

Il pourrait être un élément de réseau faisant cela. La façon de gouverner ceci serait de placer les deux machines (ou des machines d'essai) sur le même sous-réseau, puis exécutez un test de charge et vérifiez que vous ne recevez pas la même erreur.

Les autres choses qui pourraient être la cause, il pourrait être:

• Un délai d'attente, essayez d'augmenter les valeurs de délai d'attente
• Trop grande taille du message, essayez d'augmenter la taille du message a permis, la taille aussi de la demande autorisée dans IIS
• Vous pourriez frapper une valeur maximale, comme les appels ou les connexions max max voir: http://msdn.microsoft.com/en-us/library/ee377061 (v = bts.10) .aspx