Asymmetry Between Listeners and Factories

Throughout much of WCF development, we tried to preserve some fundamental symmetries between the client and server sides of messaging. A few months ago in the earlier release candidates, we ended up having to break one symmetry between channel factories and channel listeners. This broken symmetry involves the management of the lifetimes of the channels created by the factory or listener.

Our original model was that channels had a lifetime that was strictly contained within the lifetime of a channel manager. The channel manager was simply the channel factory or listener that created the channel. The channel manager maintained strong references to all of its channels and was considered the channels' owner. When the channel manager was closed, it would in turn try to close all of the channels that it had created. This allowed you to clean up any outstanding channels even if you weren't keeping careful track of the channels after creation. Architecturally, this also allowed you to design your channels with shared state stored on the channel manager. As long as your channel existed, the channel manager must also exist so you know the shared state is valid.

The change we made was to break this common channel manager model and have different behavior for channel factories and listeners. Channel factories continue to use the strong ownership model of channels. This makes it less likely that you'll accidently leak resources on the client even if you are sloppy about cleaning up your channels. Channel listeners no longer have their lifetime coupled to their channels. The reason that we did this is to allow for a smooth migration of work from one listener to another. Stopping new work requests from coming into a channel listener during migration requires shutting down that listener. In the old model, shutting down the listener causes all of the existing work requests to terminate. In the new model, you can shut down the current listener and let those existing work requests continue to completion. At the same time, you can start a new channel listener to process new work requests that come in. The channel implementation needs to be more complicated though because the channel cannot rely on the continued existence of its listener after creation.

Next time: Implementation Guidelines for GetProperty