mars
2008
Un article de Webman
Bonjour à tous,
Voici quelques temps j’ai été confronté à des Timeout avec une petite application utilisant WCF. Cette application utilisait le binding wsDualHttpBinding en mode duplex. Tant que les deux parties de l’application se trouvaient sur la même machine cela fonctionnait correctement, mais lors de tests sur des machines différentes là cela ne marchait plus, timeout et encore timeout.
Mon application utilisait des méthodes « One Way » (IsOneWay = true) avec un contrat de callback, c’est-à-dire que toutes les méthodes du service étaient « void » et ne renvoyaient rien. Pour faire vite ce procédé permet de ne pas rester bloqué sur des méthodes en attendant la fin du traitement pour avoir une réponse. Ainsi quand un client envoie une requête vers un service il n’attend pas la réponse, le client se contente d’envoyer une requête et c’est tout, le service renverra la réponse une fois le traitement terminé en utilisant le contrat de rappel. Le contrat de rappel est implémenté par des méthodes côté client. Ainsi chaque côté utilise des méthodes qui ne retournent rien, la réponse à une requête revient par l’appel d’une autre méthode dans le sens opposé. Le fonctionnement est alors asynchrone, et vos applications ne tournent pas désespérément dans le vide, ou pire, restent bloquée en attendant une réponse.
Assez d’explications, revenons en au problème que j’ai rencontré. Quand les deux parties de l’application se trouvaient sur des machines différentes j’avais inévitablement un Timeout. Je vais vous expliquer pourquoi, vous allez voir c’est vraiment très bête mais en il est très facile de perdre une heure sur un tel détail…
Voici comment était configuré le binding côté client :
<binding name="bindWsClt" clientBaseAddress="http://localhost:2701/wcfapp/">
<security mode="None"></security>
</binding>
</wsDualHttpBinding>
Vous avez trouvé l’erreur ? En fait il s’agit de l’url ! Celle-ci est définie avec localhost, ainsi quand le service veut répondre à cette adresse alors que le client se trouve sur une autre machine et bien il ne trouve tout simplement plus le client. Pour corriger cela il faut donc utiliser l’IP ou le nom de la machine où se trouve le client. Voilà à quoi ressemble le fichier de configuration une fois le problème corrigé :
<binding name="bindWsClt" clientBaseAddress="http://www.developpez.com:2701/wcfapp/">
<security mode="None"></security>
</binding>
</wsDualHttpBinding>
Ainsi lors du callback le service sait à quelle adresse il doit rappeler le client. On voit donc qu’ici avec l’utilisation d’un binding qui gère le callback il est très important de renseigner correctement la « clientBaseAddress« . Il en va évidemment de même avec l’adresse du « Enpoint » côté service mais cela pas la peine de le préciser.
Voilà c’est tout bête mais il est facile de tomber dans le piège!
Commentaires récents
- dans Microsoft.com migre 79 serveurs vers Windows Server 2008 Beta 3
- dans L’ouverture est décidément très à la mode… au tour de Microsoft
- dans Microsoft Most Valuable Professional (MVP) en 2008…
- dans Article : Design pattern Singleton avec .Net (VB.Net et C#)
- dans Article : Design pattern Singleton avec .Net (VB.Net et C#)