État de la chaîne WCF Non mis à jour

Question

J'ai un problème avec mon application WCF. J'utilise un netTcpBinding pour mon application. Et du côté client, j'utilise ClientBase <> pour se connecter à l'hôte, et ICommunicationObject.State pour vérifier si le canal est toujours disponible. Le problème est après le "receiveTimeout", la connexion TCP est coupée, mais dans le côté client, quand je vérifie l'état, il est toujours "ouvert". Et quand j'essaie de l'utiliser directement, il y a des exceptions.

Pour confirmer la déconnexion du socket TCP, j'utilise TCPView pour le surveiller. Il est coupé après le délai d'expiration. Mais l'état du canal n'est pas mis à jour. En fait, j'ajoute le journal de diagnostic dans la configuration du serveur. Et je reçois une exception juste après le timeout (en même temps la déconnexion se produit).

est ici l'exception (du côté serveur):

System.ServiceModel.CommunicationObjectAbortedException, System.ServiceModel, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089 System.Net.Sockets.SocketException , System, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089 Une erreur TCP (995: l'opération d'E/S a été interrompue en raison d'une sortie de thread ou d'une demande d'application) s'est produite lors de la transmission de données.

Et si je tente d'appeler à nouveau le service du client, du côté client, je reçois cette exception:

System.ServiceModel.CommunicationException: La connexion socket a été interrompue. Cela peut être dû à une erreur de traitement de votre message ou à un dépassement de délai de réception de l'hôte distant ou à un problème de ressource réseau sous-jacent. Je pense que c'est normal pour l'exception côté client. Mais je ne sais pas si j'ai besoin de gérer les exceptions côté serveur.

Quelqu'un a une idée?

Merci beaucoup.

Answer 1

Le CommunicationState restera comme 'Ouvert' à moins que vous n'ayez explicitement Close() il y a un défaut avec le canal. Malheureusement, dans votre scénario jusqu'à ce que vous essayez d'utiliser ledit canal, il n'y a aucun moyen de déterminer s'il est réellement disponible en dehors de la vérification d'une exception.

Je suggère que vous n'essayez pas de garder un canal ouvert après le point d'être utilisé et explicite Close() une fois que vous avez terminé.

Nous avons un wrapper qui encapsule l'appel, y compris la création d'un proxy, l'appel de service lui-même et la fermeture subséquente du canal et cela fonctionne bien.