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

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 :)

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.

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.

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.

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 ?

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.