WCF：如何诊断故障通道？
我正在为我的实验室进行一项更改，希望能够帮助诊断我们所看到的一些奇怪的通道故障现象。有一个测试应用程序使用 DuplexChannelFactory 连接到几个 Windows 服务，并且由于某种原因，该测试应用程序上的通道似乎出现了很多故障。我计划在那里实现一些重试逻辑，但如果能弄清楚它们到底出错的原因，那就太好了。
我知道通道工厂和代理对象都实现了很多接口，并且我已经使用反射器爬行了其中一些接口，但我还没有找到像我正在寻找的东西。有没有办法在这些对象发生故障后对其进行查询，以获得有关导致故障的原因的一些信息？
编辑：配置非常基本 - 绑定只是默认构造的 NetTcpBinding，服务实现有 [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)]，没有特殊的属性位于服务契约中的任何操作上。但是，我更多地询问的是诊断通道故障的一般技术，而不是诊断这种特定情况。我不希望配置细节对此产生太大影响；如果有的话，配置详细信息将是由所述诊断返回的内容，对吧？
I'm working on shipping in a change for my lab that will hopefully help diagnose some weird channel-faulting weirdness we're seeing. There's a test application that uses DuplexChannelFactory to connect to a couple windows services, and for some reason the channels on this test application seem to be faulting quite a bit. I have plans to implement some retry logic in there, but it would be great to figure out why exactly they're faulting.
I know that channel factories and proxy objects all implement a lot of interfaces, and I've used reflector to crawl through some of them, but I haven't found anything like what I'm looking for. Is there a way to query these objects after they've faulted in order to get some information about what caused the fault?
Edit: The configuration is very basic--the binding is just the default-constructed NetTcpBinding, the service implementation has [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)], and no special attributes are on any of the operations in the service contract. However, I'm asking more about general techniques in diagnosing channel faults, not diagnosing this specific case. I wouldn't expect configuration specifics to have too much impact on that; if anything, the configuration details would be something returned by said diagnostics, right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Ladislav 和 Shiraz 的答案都很好，我给了他们+1。
我可以补充的是，通常故障通道是服务器上未处理的异常的结果。当发生这种情况时，WCF 认为服务器存在根本性错误，并对通道进行故障处理，使其无法使用。
正确的方法 - 我认为应该是默认的并且免费的 - 是让服务捕获异常并创建一个FaultException并返回它（查看此表单示例 http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx）
WCF 这样做的原因不作为默认设置的原因是它更改了合同和 WSDL，因此客户端必须获取更新的 WSDL。
因此，如果我是你，我会捕获异常，记录它们，然后返回故障异常，这样我就会知道问题是什么并且通道没有故障。
Ladislav and Shiraz answers are all good and I have gave them +1.
All I can add to them is that normally a faulted channel is the result of unhandled exception on the server. When that happens, WCF thinks that there is somethig fundamentally wrong with the server and faults the channel so that it cannot be used.
The correct approach - which I believe should have been default and come for free - is for the service to catch the exception and create a FaultException and return it (look at this form example http://www.c-sharpcorner.com/UploadFile/ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx)
The reason WCF does not make as default is that it changes the contract and the WSDL so the client has to get the updated WSDL.
So if I were you, I would catch the exceptions, log them and then return a fault exception and this way I would know what the problem is and channels are not faulted.
首先是这个测试应用程序，或者是其他客户端使用的特定服务。
假设是测试客户端引起了问题。可能有两个问题：
First thing is it this test application, or are the specific services used by other clients.
Assuming that it is the test client that is causing the problem. There could be 2 problems:
您正在寻找的诊断工具称为WCF 跟踪。它通常显示通道出现故障的原因。您可以在客户端和服务器上配置它，并使用 SvcTraceViewer.exe 来浏览收集的痕迹。
Diagnostic tool you are looking for is called WCF Tracing. It usually shows why the channel has faulted. You can configure it on both client and server and use SvcTraceViewer.exe to browse collected traces.
您是否已连接到 ICommunicationObject.OnFauled
Have you hooked on to the ICommunicationObject.OnFauled