Exporter (0) Imprimer
Développer tout
Ce sujet n'a pas encore été évalué - Évaluez ce sujet

Traitement des objets de messagerie ayant généré une erreur (Faulted)

Mis à jour: mars 2014

La plupart des développeurs Windows Communication Foundation (WCF) savent qu'un objet de communication WCF doit être traité avec une précaution particulière afin de gérer la transition de l'état interne, en particulier les situations dans lesquelles l'objet WCF génère à la fin une erreur (Faulted). Souvent, la pile de communication WCF doit être réinitialisée, par exemple, en recréant un canal client afin de récupérer de cette erreur.

L'API de messagerie répartie fournit la résilience « prête à l'emploi » pour les objets de communication ayant généré une erreur en permettant de gérer et de récupérer des situations d'erreur qui peuvent rendre inutilisables les objets de communication sous-jacents. Contrairement aux clients WCF traditionnels, les clients de messagerie Service Bus qui tirent parti de l'API de messagerie répartie n'ont pas besoin d'implémenter une logique spéciale pour traiter les objets de communication en situation d'erreur (Faulted). Tous les objets de communication tels que MessagingFactory, QueueClient, TopicClient, SubscriptionClient, MessageSender, et MessageReceiver sont automatiquement détectés et récupérés après des exceptions pouvant potentiellement mettre la pile de communication dans un état non opérationnel.

Certaines opérations de messagerie telles que que Complete, Abandon et Defer ne sont pas en mesure d'assurer une récupération automatique transparente. En cas d'échec de Complete() ou de Abandon() avec l'exception MessagingCommunicationException, le seul recours est de recevoir un autre message, peut-être le même que celui qui a échoué à l'exécution, à condition qu'un consommateur en concurrence ne l'ait pas récupéré entretemps.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft. Tous droits réservés.