Discussion :

[Ishida]

Bonjour,

Je travaille actuellement avec Silverlight et WCF.
Côté serveur, j'ai une classe pour mon service:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]    
public class MyService : IMyService
{
  public void DoSomething() {... }
}

L'interface IMyService étant définie comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public interface IMyService
{
  [OperationContract]
  void DoSomething();
}

Côté client, j'ai ajouté une référence de service dans mon plugin Silverlight; ce qui a pour effet de générer le "proxy" qui va être utilisé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
MyServiceClient proxy = new MyServiceClient(GetBinding(), GetEndPoint());
proxy.DoSomethingCompleted += Blablabla...
proxy.DoSomethingAsync();

GetBinding() renvoie simplement un BasicHttpBinding créé avec BasicHttpSecurityMode.None.
GetEndPoint() le point de terminaison pour se connecter au service.

Rien de bien méchant jusqu'ici.

D'autant plus que tout fonctionne bien. L'appel au service aucun problème, il répond bien, sans erreur...
Mais où qu'il est le problème alors me diriez vous.

Et bien voilà: Si l'utilisateur laisse son navigateur avec l'application ouverte pendant un certain temps (environ 1 heure semble t'il) sans rien faire, lorsqu'il retravaille avec, dès qu'un appel au service est effectué, une exception CommunicationException se produit.
Il peut continuer à naviguer dans l'application tant qu'il n'y a pas d'intéraction avec le serveur; mais dès qu'une tentative d'appel au service est faite, l'application ne fonctionne plus, il faut la relancer.

Voilà quelques précisions du problème:
- Les sessions Timeout de IIS et dans le web.config on déjà été paramétrées à 8 heures: le problème ne vient pas de là. De plus, j'ai une autre application Silverlight sur ce serveur, et aucun problème de TimeOut. Le problème se produit également lorsque j'ai mon projet en local attaché au débuggeur de Visual Studio.
- Côté serveur, j'ai un EndPoint personnalisé me permettant une gestion d'erreur.
- Lors de l'erreur, le proxy est bien instancié, mais lors de l'appel de la méthode MahcinAsync(), l'application passe directement dans le callback MachinCompleted() avec une erreur:

aucune connexion avec le service côté serveur n'est établie. CommunicationException: Server not found.

- J'utililise Silverlight 3.0/WCF/Framework3.5sp1

Donc ma question est simple: pourquoi mon application n'est plus capable de communiquer avec le serveur après une longue période d'inactivité ?

Merci de votre aide.

Ishida

[ketan]

Bonjour,

Si le timeout pour la connection du coté serveur a bien été configurée, qu'en est-il de la connection coté silverlight ?
Il ne faut pas oublier qu'une connection est bidirectionnelle, et tu ne précise pas la configuration du coté de silverlight.

[Ishida]

Re-bonjour,

Il ne faut pas oublier qu'une connection est bidirectionnelle, et tu ne précise pas la configuration du coté de silverlight.

Je ne vois pas de quoi tu veux parler. Le client silverlight instancie une nouvelle instance de la classe MyServiceClient, qui a été générée automatiquement à partir du WSDL exposée par le serveur. Certes le canal à certaines propriétés de Timeout, telles que l'expiration suite à un appel de méthode, mais cela n'a pas de lien avec le problème proposé ici. De plus j'ai essayé en recréant systématiquement le binding et le Endpoint côté client, sans plus de succès.

De quelle configuration veux tu parler ?

[ketan]

Je voulais parler de la configuration pour le binding du coté de silverlight (celui que tu réupère via la méthode GetBinding() ).

D'après les réponse sur le forum à cette adresse, la propriété ReceivedTimeout permet de spécifier le temps maximum d'inactivité d'un binding.

[Ishida]

Bonjour,

GetBinding(): cette configuration est certes très interessante, mais je le redis, ce n'est pas celle qui m'importe ici.
Cette configuration permet en effet de paramétrer la configuration du canal entre le client et le serveur, pour gérer les délais de communications lors d'appels de méthodes. Par exemple: je demande la liste des clients; combien de temps le client va t'il attendre la réponse avant de considérer qu'il y une erreur. (Temps de réponse du serveur trop long).

Mon problème était que si l'on ne faisais pas appel au serveur pendant un certain temps (L'application reste ouverte sans être utilisée), et bien si l'on voulait à nouveau l'utiliser, cela générait une erreur dès que le client voulait interroger le serveur.

Solution: Tout vient du fichier web.config

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<serviceHostingEnvironment aspNetCompatibilityEnabled="false" />

Lorsque cet attribut a la valeur true, les demandes transmises aux services Windows Communication Foundation (WCF) passent par le pipeline HTTP ASP.NET.
Donc configurer cette option a false permet de s'affranchir de la contrainte du pipeline HTTP ASP.NET; ce qui permet d'accéder en permanence au service WCF sans passer par les états ASP.NET.
Je vous conseille vivement cette page.