Pooling du canal WCF personnalisé

Question

Nous avons développé un canal WCF personnalisé qui communique via IBM Websphere MQ.

Nous avons créé une usine de canal:

public class MqChannelFactory : ChannelFactoryBase<IRequestChannel> 

qui retourne les instances de notre chaîne:

public class MqRequestChannel : ChannelBase, IRequestChannel 

Connexion au gestionnaire de file d'attente IBM MQ est une opération coûteuse. Actuellement, nous le faisons dans Channel.OnOpen(). En suivant les directives pour l'utilisation correcte des canaux, nous sommes callign ChannelFactory.CreateChannel() chaque fois que nous avons besoin d'un canal, en envoyant le message, puis en appelant Channel.Close(). Nous supposions que ChannelFactory effectuait la mise en commun des canaux, de sorte que lorsque Channel.Close() était appelé, le canal n'était pas fermé mais renvoyé au pool. Mais, à chaque fois que nous appelons ChannelFactory.CreateChannel, un nouveau canal est instancié, et lorsque la requête est envoyée, l'ouverture coûteuse du canal est effectuée. Donc, la question: Quelle est la meilleure approche pour empêcher l'ouverture du canal à chaque demande?

Certaines des options que nous enquêtons:

• Y at-il de toute façon par la configuration de préciser que la mise en commun du canal devrait avoir lieu? Devrions-nous mettre en place notre propre mise en commun des canaux dans notre ChannelFactory?

• Devrions-nous garder notre canal ouvert pendant toute la durée de vie de l'application, en envoyant toutes les demandes à travers elle? Devrions-nous effectuer l'opération coûteuse (connexion au gestionnaire de files d'attente) dans la fabrique de canaux, que nous mettons en cache pendant la durée de vie de l'application?

Answer 1

Il n'y a vraiment aucune règle absolue quant à la meilleure option. Au départ, je dirais que la solution la plus simple serait de mettre en cache les canaux clients au niveau de l'application. En fonction de votre implémentation, cela peut nécessiter un certain travail de synchronisation, btw.

Vous pouvez potentiellement regrouper les connexions au niveau ChannelFactory. J'hésiterais à regrouper des canaux entiers (il y a toujours de la complexité), mais vous pouvez regrouper les connexions en interne et faire en sorte que les canaux acquièrent des connexions lorsque cela est nécessaire depuis la réserve détenue par leur usine de canaux.

Cela a l'avantage que ClientBase already caches ClientFactory instances à partir de .NET 3.0 SP1, ce qui peut faciliter le code de l'application (si vous l'utilisez).

L'inconvénient, cependant, est que que cela pourrait devenir plus difficile à mettre en œuvre si l'adresse de noeud final contient des informations qui est nécessaire pour ouvrir la connexion au gestionnaire de file d'attente parce que vous pouvez potentiellement créer des canaux pour les adresses finaux différents d'un seul Objet ChannelFactory. Cela signifie probablement que vous devrez l'interdire explicitement, ou que votre implémentation ChannelFactory devra peut-être conserver plusieurs pools de connexions en interne (un par adresse de point de terminaison ou quelque chose comme ça).