WCF proxy run time initialization and performance implication

I'm initializing my proxy manually through ChannelFactory class, as configurations to initialize this proxy is from some other Configuration service (not in same App.Config) and to avoid initializing cost (Service Call, Read Configuration Settings) I cached this proxy. I can't bare the cost to close this proxy after each operation because a frequent operations execution required. Timeout Configurations for this proxy is as follows.

receiveTimeout="00:10:00" 
sendTimeout="00:10:00" 
closeTimeout="00:10:00"

As per my understanding about Timeout properties at client side, status of my proxy will be Fault when timeout exceed. right?

I want to reinitialize my proxy so I've 2 option to do this.

1) I use ICommunicationObject.Faulted event Handler and when my proxy moved into faulted state in this even I reinitialize the proxy. But this implementation is not suitable because we didn't dispose the proxy properly (calling .Close() method) and it will not release the resources from service side and effect my performance.

2) I create a Thread and set it's elapsed time few seconds before proxy is going to Faulted state. Close this proxy properly by calling .Close{) method and reinitialize another object and cache it开发者_运维百科.

Please suggest me which option is good in context of performance and do let me know if some other solution exist to avoid this problem.

Thanks in advance.

if the proxy is in faulted state you can call Abort on it. If you really want to keep the proxy around depends on what you need. If you are going to use Duplex-Communication or something like this is might be good advice. If you only call the service from time to time you can go and use the proxy only during calls.

I normaly go and write myself a small proxy that just publishes Connected and Fault events. And I implement IDisposable with code that first tries to close the proxy and when a CommunicationException is thrown goes on to Abort it.

In the code that handles the communication I hold a reference to such a proxy object and dispose it on Close/Fault and open it as soon as I have a operation pending. This works rather well on the client side even when the network is not reliable. In case of Duplex-Services I just add a timer that tries to reconnect automatically if the connection is lost.

Here is a small snippet in F# demonstrating the way I use this very simple proxy - it's really nothing more but wrapping the Channel and getting connection-events out - WcfHelper is just a bunch of helper-functions to build up Adresses and Bindings - this case is a stripped down version for a DuplexService so it inherits from DuplexClientBase but the normal non-duplex case is just the same.

/// Duplex-proxy
type private MyProxy(handler, servicename: string, server : string, port : int) =
    inherit DuplexClientBase<IWcfConnector>(handler, WcfHelper.getBinding(), WcfHelper.createEndpointAddress(servicename, server, port))

    let _connectionEvent = new Event<_>()

    do
        base.InnerDuplexChannel.Closed.Add(fun _ -> _connectionEvent.Trigger(ConnectionState.Disconnected))
        base.InnerDuplexChannel.Opened.Add(fun _ -> _connectionEvent.Trigger(ConnectionState.Connected))
        base.InnerDuplexChannel.Faulted.Add(fun _ -> _connectionEvent.Trigger(ConnectionState.Disconnected))

    /// sample-Operation
    member i.TestCall(message) = base.Channel.TestCall(message)

    interface IDisposable with
        member i.Dispose() =
            try
                i.Close()
            with
            | :? CommunicationException ->
                i.Abort()