2010-10-21 3 views
3
CommunicationException was unhandled by user code 
The socket connection was aborted. This could be caused by an error processing your message 
or a receive timeout being exceeded by the remote host, or an underlying network resource 
issue. Local socket timeout was '02:48:04.9840000'. 

J'ai testé cette application pendant des mois et je viens de voir cette erreur après avoir apporté une petite modification à l'un des services. Ce n'est que quelques secondes, donc je ne pense pas que ce soit un problème de timeout.WCF: La connexion socket a été abandonnée

InnerException: System.IO.IOException: L'opération de lecture a échoué, voir exception interne

(intérieur) InnerException: System.Net.Sockets.SocketException - a été fermée force une connexion existante par l'hôte distant.

Toutes les suggestions sont grandement appréciées!

Merci à l'avance

+0

Je vous suggère de rechercher pourquoi l'hôte distant a fermé la connexion. –

+1

Eh bien, quand je débogue à travers, tout semble aller bien, mais en revenant du gestionnaire au proxy (client), l'exception est levée.Je veux dire qu'il y a plus de données qui sont autorisées, mais pas plus que d'habitude. –

+0

Avez-vous essayé le traçage WCF? –

Répondre

4

Vous rencontrez probablement des problèmes de quota tels que MaxReceivedMessageSize, MaxArrayLength, MaxStringContentLength définis dans la liaison.

Vous pouvez également consulter l'attribut MaxItemsInObjectGraph disponible dans les comportements.

8

Généralement j'ai vu cette erreur lorsque la partie adverse ne se ferme pas proprement à la connexion. Si du côté client vous avez une classe qui hérite de ClientBase<T>, vous devez appeler le Close lorsque vous avez terminé le service (en fait, ClientBase<T> implémente IDisposable afin que vous puissiez utiliser une instruction using).

Si vous utilisez un ChannelFactory<T> pour créer la connexion au service, le résultat est un proxy qui implémente le contrat mais implémente également ICommunicationObject; vous devez appeler Close lorsque vous avez terminé. Du côté du service, les choses ne sont pas les mêmes, la session (et donc le socket sous-jacent) est gérée par le client. Si le service abandonne la socket, il s'agit probablement d'une erreur, auquel cas la suggestion de Music Magi est bonne. Microsoft parle de comment s'y prendre here.

Notez que pour obtenir une image claire de ce qui se passe, vous devrez peut-être configurer le suivi pour le client et le service. Afin d'afficher les traces que vous utiliseriez SvcTraceViewer qui devrait être dans le dossier Program Files\Microsoft SDKs\Windows\v6.0A\bin ou Program Files\Microsoft SDKs\Windows\v7.0A\bin. Si vous devez suivre à la fois le client et le service, vous pouvez ouvrir les deux fichiers ensemble au SvcTraceViewer en utilisant le menu File/Add.

3

J'ai rencontré une connexion socket annulée pour différentes raisons qui, à mon avis, valent la peine d'être résolues.

En plus de ne pas avoir des valeurs suffisamment élevées dans votre MaxReceivedMessageSize, MaxArrayLength, MaxStringContentLength, MaxItemsInObjectGraph que Johann a souligné ...

Assurez-vous les types que vous sérialisation jouer bien avec WCF. Par exemple, j'avais le même problème mais j'ai alors réalisé que j'envoyais System.DBNull sur le fil qui a causé l'abandon du service. Une fois que j'ai filtré les objets DBNull, les choses ont recommencé.

Questions connexes