Question

We have developed a custom WCF channel which communicates via IBM Websphere MQ.

We have created a channel factory:

public class MqChannelFactory : ChannelFactoryBase<IRequestChannel>

Which returns instances of our channel:

public class MqRequestChannel : ChannelBase, IRequestChannel

Connecting to the IBM MQ queue manager is an expensive operation. Currently, we do this in Channel.OnOpen().

Following the guidelines for correct use of channels, we are callign ChannelFactory.CreateChannel() each time we require a channel, sending the message, then calling Channel.Close().

Our assumption was, that the ChannelFactory performed pooling of channels, so that when Channel.Close() was called, the channel was not actually closed but rather returned to the pool. But, everytime we call ChannelFactory.CreateChannel, a new channel is being instantiated, and when the request is sent, the expensive channel opening is performed.

So, the question: What is the best approach to prevent the channel being opened on every request?

Some of the options we are investigating:

• Is there anyway through configuration to specify that channel pooling should take place? Should we be implementing our own channel pooling in our ChannelFactory?

• Should we just keep our channel open for the life of the application, sending all requests through it?

• Should we perform the expensive operation (connecting to the queue manager) in the channel factory , which we cache for the life of the application?

Answer 1

There’s really no hard and fast rule as to what the best option is. Initially, I’d say the possibly easiest solution would be to cache client channels at the application level. Depending on your implementation, that might require some synchronization work, btw.

You could potentially pool connections at the ChannelFactory level. I’d be hesitant to pool entire channels (there’s always some complexity there), but you could pool connections internally and have channels acquire connections when needed from the pool held by their channel factory.

This does have the advantage that ClientBase already caches ClientFactory instances as of .NET 3.0 SP1, so that might make it easier on the application code (if you’re using it).

The downside, though, is that that this might get harder to implement if the endpoint address has information that is needed to open the connection to the queue manager because you can potentially create channels for different endpoint addresses from a single ChannelFactory object. Likely this means that you’ll need to explicitly disallow this, or that your ChannelFactory implementation might need to keep multiple connection pools internally (one per endpoint address or something like that).