WCF超时是一场噩梦

Question

我们有一堆WCF服务几乎一直在使用,使用各种绑定,端口,最大大小等.关于WCF的超级令人沮丧的事情是,当它(很少)失败时,我们无法找到它为什么它失败.有时您会收到如下所示的消息:

System.ServiceModel.CommunicationException:套接字连接已中止.这可能是由于处理消息的错误或远程主机超出接收超时或基础网络资源问题引起的.本地套接字超时为'01:00:00'.---> System.IO.IOException:无法从传输连接读取数据:远程主机强制关闭现有连接.

问题是它给你的本地套接字超时只是一个方便的尝试.它可能是也可能不是问题的原因.但好的,有时网络有问题.没什么大不了.我们可以重试或者其他什么.但这是一个巨大的问题.除了没有告诉你究竟哪个超时(如果有的话)导致失败("你的服务器端接收超时",或者某些东西,将会有所帮助)之外,WCF似乎有两种类型的超时.

超时类型#1)超时,如果增加,将增加您的操作成功的机会.所以,相关的超时是一个小时,你上传一个需要一小时二十分钟的巨大文件.它失败.你增加超时,它成功.我对这种类型的超时没有任何问题.

超时类型#2)超时仅定义您必须等待服务实际失败的时间并给出错误,但修改此超时的值不会影响成功的可能性.基本上,在服务请求的第一秒发生了某些事情,这会使事情变得糟糕.它永远不会恢复.WCF不会神奇地为您重试网络连接.很好,有时建立网络连接并不顺利.但是,如果你的超时是2小时,你必须等待整整 2个小时,它才有可能在它最终确认它不起作用并给你错误之前工作.

但是你在两种情况下看到的错误都是一样的.超时类型#2,它仍然看起来你正在超时.但是,您可以将所有超时时间增加到4年,而它所要做的就是花费4年时间才能收到错误消息.我知道类型#2存在是因为我可以做一个已知在成功后不到一分钟就完成的操作,并且需要2个小时才能失败.但是,如果我杀了它并重试,它会很快成功.(如果您想知道为什么在不到一分钟的操作中可能会有2小时超时,有时我会使用更大的文件运行操作,这可能需要一个多小时.)

因此,为了解决类型#2的问题,您希望您的超时非常快,以便您立即知道是否存在问题.然后你可以重试.但是难以克服的问题是因为我不知道哪些超时是失败的原因,我不知道哪种超时是#1型,哪些是#2型.可能有一个超时(假设客户端发送超时)在某些情况下类似于#1类型而在其他情况下类似#2.我不知道,我无法找到答案.

有没有人知道如何追踪Type#2超时,所以我可以将它们设置为低值而不必缩短实际(读取:类型#1)超时并降低成功的机会？

谢谢.

澄清第2类超时以回应Andrew Anderson的评论:

我的信念是客户端请求和开始在服务器上执行的代码之间出现问题.在我们有服务器代码指示部分进度的所有情况下,如果没有完成整个操作,它就永远不会完成一些操作.因此,服务器代码永远不会执行,执行所需的时间是无关紧要的(除了它影响我们首先设置我们的超时值以适应它).

Answer 1

我总是在长期运行的 WCF 服务中放置“心跳”消息。然后，您可以将 Type #1 超时设置为较低值（心跳调用频率的 2-3 倍），并且 Type #2 超时变得明显。