WCF 的 timeout 问题

Question

 大家好，我有一个关于wcf超时设定的问题。还请教大家。

 在WCF的客户端的设定里，有 opentimeout , closetimeout, receivetimeout, sendtimeout 四个超时设定。其中的sendtimeout我弄得狠明白，通过测试也很容易的得到了期待的结果。
  剩下的三个虽然在MSDN上有说明，可是说的不是很详细，现在我的问题是。opentimeout , closetimeout, receivetimeout 这三个超时设定，

1. 在什么情况下会发生？（编程的错误导致出错？物理网络问题？传送数据大小？）
2. 发生之后wcf 提示什么错误？（希望可以给出出错的原文）
3. 如果要通过测试故意让他们出错的话，如何测试？（如果可以的话希望能提供原代码）

我的问题有点儿苛刻，还请大家不吝赐教，谢谢！

Answer 1

呵呵，等待，学习。

---

做最好的自己

Answer 2

针对openTimeout谈一下我自己的感觉吧，系统给的提示说openTimeout是指ServiceHost开启允许占用的最大时间。我觉得很可能就是host.Open()操作的最大执行时间。{其中host是ServiceHost的一个实例}。我试过在host.Open()之前运行一个Thead.Sleep()，其中睡眠的时间大于openTimeout所设定的值，但是服务依然会正常开启。而且服务端的catch(Execption)没有捕获任何异常。
  期待高手指点。

Answer 3

我现在就可以给你个接受数据超时的错误，我测试代码的时候发现的，刚才也回复了别人的帖子，现在也没理想的解决办法，目前还在收集中。WCF分布式开发常见错误解决(10)：套接字连接中断，The socket connection was aborted，你或许能很好的理解这个错误。服务端处理大量数据的时候超时（超过设定的时间），就会出现这个错误。我这里使用的tcp绑定传输图片数据。

---

you have a dream,you gonna protect it!

Answer 4

opentimeout , closetimeout, receivetimeout :
1.在什么情况下会发生？（编程的错误导致出错？物理网络问题？传送数据大小？）
2.发生之后wcf 提示什么错误？（希望可以给出出错的原文）
3.如果要通过测试故意让他们出错的话，如何测试？（如果可以的话希望能提供原代码）

我尝试详细解答你的问题：什么情况会出现这个错误，以及如何测试。
1.opentimeout：常见的就是服务代理端打开超时。
closetimeout：与open对应，代理长时间不能关闭，释放服务资源，会超出时间出错。
  receivetimeout：简单理解就是接收超时，导致服务出错。
2.receivetimeout我目前测试的代码出错的就是，套接字连接中断，The socket connection was aborted，
其他两种情况暂时没测试。WCF分布式开发常见错误解决(10)：套接字连接中断，The socket connection was aborted
3.具体的测试思路：
   opentimeout：可以在服务代理open方式里添加延时代码，而配置opentimeout属性为一个较小的时间值，使服务代理open超时；
   closetimeout：与打开类似，调用关闭方法添加代码，延时，设置closetimeout属性为一个较小的时间值，使得关闭超时。
   receivetimeout：上传大量的数据，如图片文件数据等，很容易超时出错。设置receivetimeout属性为一个较小的时间值，容易出现超时错误。
  示例代码我会上传到我的博客控件，最近的一个流操作文章调试的代码就多次出现这个错误。我也在尝试解决。
以上建议希望对你有所帮助。

---

you have a dream,you gonna protect it!

Answer 5

xuhongxin 兄 说的很对，在 Open 方法里加延时，无法得到预期的结果

其实现在，也就是 Open 和 Close 的 timeout 不太明白，真的是 做不出测试代码，心里便很闹挺

Answer 6

WidelySKy 你好，

     请问你的SendTimeOut 是如何模拟出来的，我的程序中，经常会出现SendTimeOut超时，平均5000此会有 150次TimeOut，请问能帮我解决问题吗

问题见：http://social.msdn.microsoft.com/Forums/zh-CN/wcfzhchs/thread/68a34df5-ceda-4489-85d8-9f79724f3388/

---

Welcome to Gavin Luo `s blog