WCF - 重试不起作用？
我的绑定有以下配置：
<binding name="wshttp" openTimeout="00:01:00" sendTimeout="00:02:00" receiveTimeout="00:03:00" closeTimeout="00:04:00">
..snap
<reliableSession inactivityTimeout="00:05:00" maxRetryCount="8" ordered="true"/>
..snap
</binding>
我的期望是，当客户端代理在 2 分钟内无法发送时，应该重试请求。然而：
16:37:49,242 信息 启动流程
16:39:49,588 致命 请求操作未在指定的超时 00:02:00 内完成
因此应用程序会在 2 分钟内引发错误，并且不会重试该请求。我应该怎么做才能让它开始重试？
I have the following config for my binding:
<binding name="wshttp" openTimeout="00:01:00" sendTimeout="00:02:00" receiveTimeout="00:03:00" closeTimeout="00:04:00">
..snap
<reliableSession inactivityTimeout="00:05:00" maxRetryCount="8" ordered="true"/>
..snap
</binding>
My expectation here is, that when the client proxy fails to send within 2 minutes, the request should be retried. However:
16:37:49,242 INFO Start process
16:39:49,588 FATAL The request operation did not complete within the allotted timeout of 00:02:00
So the application throws an error within 2 minutes, and doesn't retry the request. What should I do to get it to start retrying?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
WS-ReliableMessaging 的 WCF 实现并非以这种方式工作。如果代理操作超时，则不会执行（进一步）重试。该协议的重试逻辑适用于已传递到底层传输但尚未在 RM 层确认的消息，最终受 MaxRetryCount 和 InactivityTimeout。
一旦您从代理通道收到 CommunicationException 或 TimeoutException，您就可以考虑终止会话。此时，您需要重新连接并重新开始（或者如果您知道您“停止”的位置并保存一些您可能能够恢复的状态 - 但此逻辑将由您负责实现）。
基本上，您应该传递一个超时值，该值代表您愿意等待通信操作完成的最长时间。如果失败，则必须 Abort() 并重新开始。
The WCF implementation of WS-ReliableMessaging does not work that way. If a proxy operation times out, no (further) retries will be performed. The retry logic of the protocol applies to messages that have been passed through to the underlying transport but have not been acknowledged at the RM layer, bounded ultimately by the MaxRetryCount and the InactivityTimeout.
Once you receive a CommunicationException or TimeoutException from your proxy channel, you can consider the session to be terminated. At this point, you'll need to reconnect and start over (or if you know where you "left off" and save some state you might be able to recover -- but this logic would be your responsibility to implement).
Basically, you should pass a timeout value which represents the longest duration you're willing to wait for the communication operation to complete. If that fails, then you must Abort() and start over.