我有一个相当直接的WCF服务,为一堆智能客户端执行单向文件同步。我注意到,在通话过程中出现网络或服务中断时,客户端将停止与服务器通信,直到整个应用程序重新启动。WCF客户端挂起服务中断
该服务使用BasicHttpBinding
运行,并使用IIS6(.svc页面),使用transferMode="Streamed"
和messageEncoding="Mtom"
。该服务被配置为使用默认的InstanceContextMode(我认为它是Per Call?)和ConcurrencyMode = Single。它使用默认的限制行为,但我处于没有其他人正在击中的独立测试环境中。
客户端是Windows服务。我使用这个ServiceProxyHelper确保连接是Close()
'd或Abort()
'd当Dispose()
'd,虽然没有会话,所以我不认为这甚至很重要。发生错误时,客户端对象被丢弃,然后超出范围。在检测到异常之后,服务会等待一段时间,然后创建一个新的客户端对象并再次尝试。所以它应该从失败中恢复,但由于某种原因,后续对该服务的所有调用都会失败。
我可以通过启动客户端来可靠地重现这一点,允许它传输几个文件,然后重新设置服务器。首先,客户端通常显示“服务太忙”错误(映射到在应用程序重新启动期间获得的IIS 503错误)。之后,所有后续的服务呼叫超时。据我所知,这些呼叫甚至没有被客户尝试。我启用了跟踪,看到的是:超时错误,后面跟着一个“无法通过HTTP发送请求消息”的警告,接着是另一个超时错误。
疯狂的事情是,当我配置客户端使用Fiddler(端口8888)作为app.config中的代理时,一切都按需要工作。所以不知何故Fiddler作为代理正在关闭或终结某种WCF本身不存在的连接。
想法?
编辑2009-10-30 8:54 PM:将服务属性更改为:InstanceContextMode = Single和ConcurrencyMode = Multiple。没有不同。
在'WebRequest'中有关于100继续功能的已知错误。 http://regis.decamps.info/blog/2010/12/c-bug-in-webrequest/ – rds 2011-01-03 18:15:51