WCF体验之旅(6):在Winform Application中调用Duplex Service出现Timeout Exception的原因和解决方案
来源:博客园 作者:Artech 出处:巧巧读书 2008-03-18 进入讨论组图2
我们从上面的Screen Shot中可以看到这样一个很有意思的现象,运算结果被成功的显示,显示,但是有个Exception被抛出:”This request operation sent to http://localhost:6666/myClient/4f4ebfeb-5c84-45dc-92eb-689d631b337f did not receive a reply within the configured timeout (00:00:57.7300000). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.”。
2、原因分析
在我开始分析为什么会造成上面的情况之前,我要申明一点:由于找不到任何相关的资料,以下的结论是我从试验推导出来,我不能保证我的分析是合理的,因为有些细节我自己都还不能自圆其说,我将在后面提到。我希望有谁对此了解的人能够指出我的问题, 我将不胜感激。
我们先来看看整个调用过程的Message Exchange过程,通过前面相关的介绍,我们知道WCF可以采用三种不同的Message Exchange Pattern(MEP)——One-way,Request/Response,Duplex。其实从本质上讲,One-way,Request/Response是两种基本的MEP, Duplex可以看成是这两种MEP的组合——两个One-way,两个Request/Response或者是一个One-way和一个Request/Response。在定义Service Contract的时候,如果我们没有为某个Operation显式指定为One-way (IsOneWay = true), 那么默认采用Request/Response方式。我们现在的Sample就是由两个Request/Response MEP组成的Duplex MEP。
从上图中我们可以很清楚地看出真个Message Exchange过程,Client调用Duplex Calculator Service,Message先从Client传递到Service,Service执行Add操作,得到运算结果之后,从当前的OperationContext获得Callback对象,发送一个Callback 请求道Client(通过在Client注册的Callback Channel:http://localhost:6666/myClient)。但是,由于Client端调用Calculator Service是在主线程中,我们知道一个UI的程序的主线程一直处于等待的状态,它是不会有机会接收来自Service端的Callback请求的。但是由于Callback Operation是采用Request/Response方式调用的,所以它必须要收到来自Client端Reply来确定操作正常结束。这实际上形成了一个Deadlock,可以想象它用过也不能获得这个Reply,所以在一个设定的时间内(默认为1分钟),它会抛出Timeout 的Exception, Error Message就像下面这个样子。
”This request operation sent to http://localhost:6666/myClient/4f4ebfeb-5c84-45dc-92eb-689d631b337f did not receive a reply within the configured timeout (00:00:57.7300000). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.”。
3、解决方案
方案1:多线程异步调用
既然WinForm的主线程不能接受Service的Callback,那么我们就在另一个线程调用Calculator Service,在这个新的线程接受来自Service的Callback。
于是,我们改变Client的代码:
|
通过实验证明,这种方式是可行的。
文字:http://www.qqread.com/net-case/j401805.html相关专题
- 数字化校园网解决方案 (5675篇文章)
- 大型实用解决方案专题 (5190篇文章)
- 应用解决方案 (5190篇文章)
- 中小型应用解决方案 (5190篇文章)
- 多媒体应用解决方案 (5965篇文章)
- 行业解决方案 (5190篇文章)
- 行业解决方案 (5190篇文章)
- 中小企业防病毒解决方案 (6048篇文章)
- 整合Adaptec、QLogic和昆腾产品的存储解决方 (21次浏览)
- 解析“系统资源不足”的形成与解决方案 (16次浏览)
- WATM的企业实现SLA的解决方案 (9次浏览)
- 城市热点助力黑龙江高校校园网建设 (9次浏览)
- H3C首推企业级802.11n产品 扩大无线解决方案 (9次浏览)
- WATM视频会议应用保障解决方案 (8次浏览)
- 使用Rational解决方案实现精益软件交付过程 (8次浏览)
- 智能新容灾 构建新存储:IPStor智能容灾解决方 (7次浏览)
- 解决南北网络瓶颈的前沿方案详解 (7次浏览)
- 中国科学院存储系统资源环境数据中心解决方案 (6次浏览)





