WCF 代理运行时初始化和性能影响

Question

我通过 ChannelFactory 类手动初始化我的代理，因为初始化此代理的配置来自其他一些配置服务（不在同一 App.Config 中），并且为了避免初始化成本（服务调用、读取配置设置），我缓存了此代理。我无法承受每次操作后关闭此代理的成本，因为需要频繁执行操作。该代理的超时配置如下。

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

根据我对客户端超时属性的理解，当超时超过时，我的代理状态将是故障。正确的？

我想重新初始化我的代理，所以我有两个选择来执行此操作。

1）我使用 ICommunicationObject.Faulted 事件处理程序，当我的代理进入故障状态时，即使我重新初始化代理。但这种实现并不合适，因为我们没有正确处理代理（调用 .Close() 方法），并且它不会从服务端释放资源并影响我的性能。

2）我创建一个线程并设置它在代理进入故障状态之前几秒钟的经过时间。通过调用 .Close{) 方法正确关闭此代理，并重新初始化另一个对象并缓存它。

请建议我哪个选项在性能方面效果更好，并让我知道是否存在其他解决方案来避免此问题。

提前致谢。

Answer 1

如果代理处于故障状态，您可以对其调用 Abort。
如果您真的想保留代理取决于您的需要。如果您要使用双工通信或类似的东西可能是个好建议。如果您只是偶尔调用该服务，则可以仅在调用期间使用代理。

我通常会自己编写一个小型代理，仅发布“已连接”和“故障”事件。我使用首先尝试关闭代理的代码实现 IDisposable，然后在引发 CommunicationException 时继续中止代理。

在处理通信的代码中，我保留对此类代理对象的引用，并将其处理为“关闭/故障”，并在有待处理的操作时立即将其打开。
即使网络不可靠，这在客户端也能很好地工作。
对于双工服务，我只需添加一个计时器，如果连接丢失，该计时器会尝试自动重新连接。

这是 F# 中的一个小片段，演示了我使用这个非常简单的代理的方式 - 它实际上只不过是包装 Channel 并获取连接事件 - WcfHelper 只是一堆用于构建地址和绑定的辅助函数 - 这种情况是 DuplexService 的精简版本，因此它继承自 DuplexClientBase，但正常非双工情况是相同的。

/// 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()