c# - 为什么我的 WCF channel 失败？

Question

我有一台计算机正在运行一个程序，该程序在另外 4 台计算机上管理多达 48 个单独的进程。我设置了 WCF 服务(每个进程一个):

    public void StartService(Uri uri, string identifier)
    {
        unitMetaData = identifier;
        var binding = new WSDualHttpBinding(WSDualHttpSecurityMode.None);
        binding.ReliableSession.InactivityTimeout = TimeSpan.FromDays(20);
        var reader = binding.ReaderQuotas as XmlDictionaryReaderQuotas;
        reader.MaxStringContentLength = WCFContentSize; // 16777216
        service = new ServiceHost(this, uri);
        service.Faulted += TestService_Faulted;
        service.AddServiceEndpoint(
            typeof(IController),
            binding,
            identifier);
        service.Open();
    }

这是远程进程的代码:

    public void Connect()
    {
        // External binding used to change the WCF XML text content size
        var binding = new WSDualHttpBinding(WSDualHttpSecurityMode.None);
        binding.ReliableSession.InactivityTimeout = TimeSpan.FromDays(20);
        var reader = binding.ReaderQuotas as XmlDictionaryReaderQuotas;
        reader.MaxStringContentLength = WCFContentSize; // 16777216
        DuplexChannelFactory<IController> factory = new DuplexChannelFactory<IController>(new InstanceContext(this), binding);
        controllerChannel = factory.CreateChannel(new EndpointAddress(controllerAddress, new DnsEndpointIdentity(controllerAddress.DnsSafeHost), new System.ServiceModel.Channels.AddressHeaderCollection()));
        ((IClientChannel)controllerChannel).OperationTimeout = TimeSpan.FromSeconds(ChannelOperationTimeoutInSeconds); // 300
        controllerChannel.RequestTestData();
    }

我有一些代码会调用远程“Ping()”函数，该函数大约每 30 秒在每个远程进程上简单地返回字符串“Pong”。我这样做是为了确保连接保持打开状态，因为我遇到了 ReliableSession 超时问题。有时(对于生产代码来说太常见了)我从一个通常是多个测试进程连接到的服务中得到以下异常:

An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.ServiceModel.CommunicationObjectFaultedException: The communication object, System.ServiceModel.Channels.ServerReliableDuplexSessionChannel, cannot be used for communication because it is in the Faulted state.

Server stack trace: 
   at System.ServiceModel.Channels.TransmissionStrategy.WaitQueueAdder.Wait(TimeSpan timeout)
   at System.ServiceModel.Channels.TransmissionStrategy.InternalAdd(Message message, Boolean isLast, TimeSpan timeout, Object state, MessageAttemptInfo& attemptInfo)
   at System.ServiceModel.Channels.ReliableOutputConnection.InternalAddMessage(Message message, TimeSpan timeout, Object state, Boolean isLast)
   at System.ServiceModel.Channels.ReliableDuplexSessionChannel.OnSend(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.DuplexChannel.Send(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at SEL.MfgTestDev.ESS.ServiceContracts.ITestProcessClient.Ping()
   at SEL.MfgTestDev.ESS.Testing.Service.TestService.Ping() in C:\Projects\Mfg_TestDev_ESS_Rev3\branches\MSU-5-18-2010\ESS.Testing.Service\TestService.cs:line 349

这是怎么回事？为什么它突然以故障状态结束。有什么方法可以找出连接出现故障的原因吗？

Answer 1

这对生产环境来说不是个好主意，但您可以尝试打开 WCF tracing在服务器和客户端上。希望您能找到更好的错误描述。

顺便说一句。您在可靠 session 方面遇到问题，因为它在 10 分钟不活动后超时。您为可靠 session 设置了不活动超时，但在绑定(bind)时也有接收超时，默认为 10 分钟。如果 10 分钟内没有消息到达，应用程序 session 将关闭 = 服务实例将被销毁，可靠 session 也将关闭。

编辑:

问题描述不充分。建筑也很奇怪。没有一项服务通过双工 channel 与 48 个客户端通信，而是 48 个相同的服务通过双工 channel 与一个 1 客户端通信。这当然会增加常见场景中不知道的其他问题，因此确实需要诊断(跟踪/性能计数器)!

当检查 Connect 方法的代码时，它甚至看起来客户端回调是与所有 48 个服务通信的单例，不是吗？该回调使用什么并发模式？如果并发模式为单一，则在调用回调时可能会出现超时问题，因为消息大小设置为 16MB。如果所有 48 个进程同时发送 16MB 消息，它们将按 FIFO 顺序排队和处理。默认设置要求在 30s 内处理，否则会出现超时异常， channel 出现故障。如果并发模式是 multiply，回调实现中仍然可能存在一些同步问题。