[WCF] Quand faut-il Close() le proxy ?

Version imprimable

01/10/2010, 12h54
DaMo`

[WCF] Quand faut-il Close() le proxy ?

Bonjour,

J'ai fait pas mal de recherches mais je trouve beaucoup de réponses différentes ...

J'aimerais savoir à quel moment il faut faire un closeAsync() d'un proxy, dans mon cas je crée un proxy par page (ou UserControl) et je vois pas trop à quelle moment (ou à quelle événement) je vais devoir CloseAsync(). J'aimerais savoir quelle la meilleur pratique à utiliser, comment gérez vous vos proxy ? Combien d'instances vous créez ? est ce que vous utilisez le CloseAsync() et à quelle moment.

Merci

Tu fais un Close dans les callback des méthodes qui sont appelées.

Ex:
Code:

1 2 3 4 5 6 7 8 Proxy p = new Proxy(); p.SendAsyncCompleted = Test; p.SendAsync(); private void Test(object sender, Args a) { (sender as Proxy).CloseAsync(); }

01/10/2010, 14h52
Samuel Blanchard

Normalement le Channel Factory ne s'en charge pas tout seul ?
01/10/2010, 15h04
DaMo`

Sachant que j'ai un proxy par page, si je le ferme dans les callbacks faudra que je le réouvre à chaque fois non ? C'est quoi l'intérêt d'avoir un proxy par appel ?
01/10/2010, 15h26
Samuel Blanchard

Je ne suis pas un expert dans le domaine mais normalement les proxys sont bridés à 2 appels simultanément (un peu comme un navigateur). donc cela permet d'outre passer ce problème (qui n'en ai pas un) que de créer un nouveau proxy à chaque appel. De plus la connection à ton serveur n'a, la plus part du temps, pas besoin d'être up en permanence. Donc fermer le proxy le plus rapidement possible peut être une bonne pratique pour libérer des ressources.
01/10/2010, 15h33
Thomas Lebrun

Citation:

Envoyé par DaMo`

Sachant que j'ai un proxy par page, si je le ferme dans les callbacks faudra que je le réouvre à chaque fois non ? C'est quoi l'intérêt d'avoir un proxy par appel ?

D'une manière générale, c'est comme avec les bases de données: il faut ouvrir la connexion le plus tard possible et la fermer le plus tot possible.
01/10/2010, 15h45
DaMo`

Donc juste histoire de résumer pour être sur, donc apparemment il vaut mieux créer un proxy à chaque appel, est ce que c'est donc quelque chose que vous faites en production peu importe le nombre d'appels WCF que vous allez faire ?
01/10/2010, 15h46
Samuel Blanchard

Pour ma part oui et sans CloseAsync :)
01/10/2010, 16h10
DaMo`

Citation:

Envoyé par Samoteph

Pour ma part oui et sans CloseAsync :)

Tu te désinscris juste de tes callbacks ?
01/10/2010, 16h15
Samuel Blanchard

exactement !
01/10/2010, 16h35
DaMo`

ok whaou sa va me faire mal aux dents de réécrire tout mes appels ....
Est ce que tu t'es fait un petit wrapper pour gérer le proxy, ou est ce que tu crées juste un nouveau proxy avant chaque appel async ?

j'utilise une méthode statique qui me permet de récupérer le service. C'est assez pratique par exemple si tu veux fixer dynamiquement l'adresse du serveur auquel tu accèdes.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public void Load() { MonService service = ServiceHelper.GetService(); // un nouveau service est renvoyé service.AppelMaMethodeCompleted += MaMethodeCompleted; service.AppelMaMethodeAsync(); } public void MaMethodeCompleted(...) { service.AppelMaMethodeCompleted -= MaMethodeCompleted; ... traitement }

Oki, j'ai un gros doute si je fais ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
MonService service;
public void Load()
{
service = ServiceHelper.GetService(); // un nouveau service est renvoyé
service.AppelMaMethodeCompleted += MaMethodeCompleted;
service.AppelMaMethodeAsync();
 
service = ServiceHelper.GetService(); // un nouveau service est renvoyé
service.AppelAutreMaMethodeCompleted += AutreMaMethodeCompleted;
service.AppelAutreMaMethodeAsync();
}
 
public void MaMethodeCompleted(...)
{
   service.AppelMaMethodeCompleted -= MaMethodeCompleted;
   ... traitement
}
 
public void AutreMaMethodeCompleted(...)
{
   service.AutreMaMethodeCompleted-= AutreMaMethodeCompleted;
   ... traitement
}

Est ce que sa fonctionnera sans problème ? Des problèmes comme des callbacks qui se perdent ou qui se retrouve dans un autre callback

Aucun problème même si faire appel à la methode GetService deux fois sur un temps aussi cours n'a pas d'interêt.
Code:

1 2 3 4 5 6 7 8 9 10 11 public void Load() { service = ServiceHelper.GetService(); // un nouveau service est renvoyé service.AppelMaMethodeCompleted += MaMethodeCompleted; service.AppelMaMethodeAsync(); //service = ServiceHelper.GetService(); // un nouveau service est renvoyé service.AppelAutreMaMethodeCompleted += AutreMaMethodeCompleted; service.AppelAutreMaMethodeAsync(); }
Dans le deux cas cela fonctionne.

Citation:

Des problèmes comme des callbacks qui se perdent ou qui se retrouve dans un autre callback

Si tu t'embrouille pense a l'evenement Click d'un Bouton, c'est le même principe.

01/10/2010, 18h05
Skyounet

Tiens çe me fait penser, dans l'appli qu'on fait au boulot on crée un client par appel mais et on utilise des delegate anonymes pour les Completed.

Est-ce que mes objets sont quand même passés au GC ?

Y'a pas un système de weak events ?
01/10/2010, 18h05
DaMo`

Oki merci beaucoup samoteph pour tes réponses, ainsi que thomas :ccool:

edit : oups skyounet qui a posté en même temps je close pas le topic
01/10/2010, 18h23
Samuel Blanchard

Citation:

Tiens çe me fait penser, dans l'appli qu'on fait au boulot on crée un client par appel mais et on utilise des delegate anonymes pour les Completed.

Est-ce que mes objets sont quand même passés au GC ?

Normalement, c'est source de MemoryLeaks car tu ne disposes pas d'une référence pour te désabonner.

Citation:

It is important to notice that you cannot easily unsubscribe from an event if you used an anonymous function to subscribe to it. To unsubscribe in this scenario, it is necessary to go back to the code where you subscribe to the event, store the anonymous method in a delegate variable, and then add the delegate to the event. In general, we recommend that you do not use anonymous functions to subscribe to events if you will have to unsubscribe from the event at some later point in your code. For more information about anonymous functions, see Anonymous Functions (C# Programming Guide).

tiré de http://msdn.microsoft.com/en-us/library/ms366768.aspx

Moi j'avais pris l'habitude de créer une variable statique dans la App.xaml.cs
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public static ServiceReference1.ServiceClient MonServiceClient { get; set; } public App() { this.Startup += this.Application_Startup; this.Exit += this.Application_Exit; this.UnhandledException += this.Application_UnhandledException; MonServiceClient = new ServiceReference1.ServiceClient(); InitializeComponent(); }
Afin de pouvoir l'utiliser facilement dans n'importe qu'elle page sans avoir le reinstancier à chaque fois, ce n'est donc pas une bonne pratique du tout ??

Code:

App.MonServiceClient.GetMethodeCompleted +=...

Si j'ai bien compris on instancie un ServiceClient à chaque fois que j'ai un appel de méthode (Async) à faire ??

04/10/2010, 16h39
Samuel Blanchard

Citation:

Moi j'avais pris l'habitude de créer une variable statique dans la App.xaml.cs

Il est vrai que c'est assez tentant de créer le service une fois pour toute. Ton application devrait fonctionner normalement et se protège des problèmes de MemoryLeaks (car les abonnements aux evenements s'effectuent une seule fois). mais je n'ai jamais vu cette approche danc aucun des exemples vu sur le net.

Outre la libération de ressources inutilement conservée et le nombre d'appel successif bridé (à vérifier) je pense que la raison principale est que le Channel crée par ton proxy n'est pas Thread safe. C'est à dire qu'il ne peut être appelé plusieurs fois en même temps sans se mettre, potentiellement, dans un état instable.

Même si la chose me semble très probable, Comme je te l'ai dit au début du Thread, je ne suis pas un expert de WCF et j'aimerai bien avoir confirmation de ce que j'avance par une star.
05/10/2010, 14h45
Mozofeuk

Citation:

Ton application devrait fonctionner normalement et se protège des problèmes de MemoryLeaks

Mes applications fonctionnent très bien jusqu'à aujourd'hui mais si ce n'est pas propre j'aimerais savoir qu'elle est la bonne manière de procéder ??

:aie: C'est quoi les problème de MémoryLeak ??

Citation:

je pense que la raison principale est que le Channel crée par ton proxy n'est pas Thread safe

:aie: Là encore je crois ne pas tout avoir saisie désolé !!

Cordialement MoZo
05/10/2010, 15h42
Samuel Blanchard

Citation:

C'est quoi les problème de MémoryLeak ??

un MemoryLeak, c'est quand le Garbage collector (GC) n'arrive pas à faire correctement son travail de balayeur de mémoire. C'est à dire qu'un objet ne peut être libéré en mémoire alors qu'il ne sert plus car il est lié par un autre objet qui lui est toujours en fonctionnement.

Typiquement lorsqu'un objet A s'abonne à un évenement sans jamais se désabonner et que le delegate se trouve être une méthode d'un objet B qui doit lui rester en fonctionnment, l'objet A ne pourra pas être nettoyer par le GC à cause de cette liaison.

Citation:

je pense que la raison principale est que le Channel crée par ton proxy n'est pas Thread safe

Un objet Thread safe est un objet que l'on peut appeler de plusieurs endroits (Thread) différents et/ou en même temps, sans que son fonctionnement ne soit affecté.

J'espère que c'est plus clair :)
05/10/2010, 23h23
Pragmateek

Citation:

Outre la libération de ressources inutilement conservée et le nombre d'appel successif bridé (à vérifier)

C'est la stack HTTP sous-jacente qui bride, non ?
Dans ce cas 1 ou 100 proxys c'est pareil, tant qu'ils ne font pas des requêtes simultannées.

Citation:

je pense que la raison principale est que le Channel crée par ton proxy n'est pas Thread safe. C'est à dire qu'il ne peut être appelé plusieurs fois en même temps sans se mettre, potentiellement, dans un état instable.

A priori s'il est créé sur le thread UI il n'y a pas de risques puisqu'il n'est accessible que par celui-ci.
06/10/2010, 09h37
Samuel Blanchard

Citation:

C'est la stack HTTP sous-jacente qui bride, non ?
Dans ce cas 1 ou 100 proxys c'est pareil, tant qu'ils ne font pas des requêtes simultannées.

Pour la stack HTTP, je ne sais pas. C'est possible :)
Mais toutes la problématique vient en effet des requetes simultanées.

Citation:

A priori s'il est créé sur le thread UI il n'y a pas de risques puisqu'il n'est accessible que par celui-ci.

Vu que les appels au Proxy sont asynchrones je peux appeler en parallèle plusieurs de ses méthodes quasiment en même temps. La problématique du Thread safe devrait donc se poser.
06/10/2010, 11h27
Pragmateek

Citation:

Vu que les appels au Proxy sont asynchrones je peux appeler en parallèle plusieurs de ses méthodes quasiment en même temps. La problématique du Thread safe devrait donc se poser.

Au niveau du code utilisateur oui cette problématique se pose, mais je ne pense pas pour le channel lui-même.
C'est une constatation empirique :aie:, utilisant toujours un seul client, et n'ayant jamais eu de problème de concurrence à ce niveau.
Après c'est comme toujours, ça marche ... jusqu'au jour où ça ne marche plus.
06/10/2010, 14h46
DaMo`

Citation:

Envoyé par seriousme

Au niveau du code utilisateur oui cette problématique se pose, mais je ne pense pas pour le channel lui-même.
C'est une constatation empirique :aie:, utilisant toujours un seul client, et n'ayant jamais eu de problème de concurrence à ce niveau.
Après c'est comme toujours, ça marche ... jusqu'au jour où ça ne marche plus.

Mais tu fais quoi dans le cas ou le channel passe à l'état "Faulted" dans ton application ?
06/10/2010, 19h36
Pragmateek

Citation:

Mais tu fais quoi dans le cas ou le channel passe à l'état "Faulted" dans ton application ?

Jamais eu de soucis à vrai dire, donc aucune idée des conséquences.
Ce qui est sûr c'est que quand une exception est lancée, catchée et gérée, je peux continuer à utiliser mon client comme auparavant.
Mais en effet, bien que ça fonctionne parfaitement, ce n'est pas forcément une bonne pratique.

Fuseau horaire GMT +2. Il est actuellement 20h11.