.net - WCF 超时是一场噩梦

Question

我们有一堆几乎所有时间都在工作的 WCF 服务，使用各种绑定(bind)、端口、最大大小等。关于 WCF 最令人沮丧的是，当它(很少)失败时，我们无能为力找出它的原因失败的。有时您会收到如下所示的消息:

System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '01:00:00'. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

问题是它给你的本地套接字超时仅仅是为了方便。它可能是也可能不是问题的原因。但是好的，有时网络会出现问题。没什么大不了的。我们可以重试什么的。但这是一个巨大的问题。除了无法告诉您究竟是哪个超时(如果有)导致失败(“您的服务器端接收超时已超出”或其他内容会有所帮助)之外，WCF 似乎有两种类型的超时。

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

超时类型 #2) 超时仅定义您必须等待服务实际失败并给您错误的时间，但修改此超时的值不会影响成功的机会。基本上，在服务请求的第一秒发生了一些事情，这把事情搞砸了。它永远不会恢复。 WCF 不会神奇地为您重试网络连接。好吧，有时建立网络连接并不顺利。但是，如果你的超时时间是 2 小时，你必须 等待整整 2 个小时，在它最终承认它没有工作并给你错误 之前它没有机会工作。 .

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

因此，为了解决 Type #2 的问题，您希望您的超时非常快，以便您立即知道是否存在问题。然后你可以重试。但是无法克服的问题是，因为我不知道哪些超时是失败的原因，所以我不知道哪些超时是Type#1，哪些是Type#2。可能有一个超时(比如说客户端发送超时)，在某些情况下类似于 Type #1，在其他情况下类似于 Type #2。我不知道，也没有办法知道。

有谁知道如何追踪 Type #2 超时，以便我可以将它们设置为低值，而不必缩短实际(阅读:Type #1)超时并降低成功的机会？

谢谢你。

针对 Andrew Anderson 的评论澄清类型 #2 超时:

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

Answer 1

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