J'ai une classe proxy (générique) personnalisée que j'utilise pour me connecter à mes services WCF. L'une des fonctionnalités que je souhaite fournir avec cette classe est la capacité à "récupérer" des pannes de service (c'est-à-dire des canaux de communication défectueux) et de l'arrêt. Pour ce faire, j'obtiens une référence au canal de service et je m'abonne aux événements ICommunicationObject.Closed et ICommunicationObject.Faulted. Lorsque ces événements se produisent, je lance une procédure de "récupération" qui tente essentiellement de rétablir une connexion au service toutes les quelques secondes. L'hypothèse est que si le service devient indisponible, pour quelque raison que ce soit, il sera bientôt disponible à nouveau et l'application cliente pourra reprendre où elle était.Problème lors de la réaction des proxys WCF à l'arrêt du service
J'ai deux services. Le service A nécessite un contrat de rappel et le service B ne le fait pas. Le service A utilise un canal duplex, ce que le service B ne fait pas. Les deux nécessitent des sessions. Le service A crée implicitement une session; le service B a des opérations IsInitiating et IsTerminating définies. Voici le (un peu confus) Je vois le comportement:
service A
- arrêt Graceful -> l'événement Faulted est élevé et peut être manipulé par le proxy, mais pas l'événement fermé.
- Arrêt "dur" -> comme ci-dessus.
service B
- arrêt Graceful - aucun événement est déclenché.
- Arrêt "dur" - aucun événement n'est déclenché.
Notez que les deux services utilisent la même classe proxy. La seule différence est dans la façon dont ils sont initialisés. Le proxy A utilise une fabrique de canaux duplex et doit donc créer un contexte d'instance auquel est transmise une instance implémentant le contrat de rappel du service A. Le proxy B utilise simplement une usine de canaux "ordinaire".
Des idées?
Un grand merci, J.
Salut, ont eu un problème similaire. Avez-vous eu du succès avec ça? – Klee