wcf: The server did not provide a meaningful reply; this might be caused by a contract mismatch

         今天记录一下wcfclient调用wcfserver查询数据时引发的一个异常的解决办法。

         首先，解决办法是：延长管道的操作超时时间

this.InnerChannel.OperationTimeout = System.TimeSpan.FromMinutes(15);

this是System.ServiceModel.ClientBase<TChannel>的对象实例。

         接下来感兴趣的朋友可以看看下面的问题发现和解决的过程，写的有点啰嗦，望见谅。

         公司的ASP.NET Core Web项目有些功能需要通过查询WCF服务获取数据，所以我就封装了个netcore的WCFClient供Web项目调用，其中大部分功能都能正常查询到数据，但有一个功能偶尔会失败，记录到日志的异常信息是：The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error. 翻译过来是：服务器没有提供有意义的回复；这可能是由于协议不匹配造成的，或会话提前关闭或内部服务器错误。异常的第一句话是要点，后面解释给了3种可能的原因。

          因为异常说“服务器没有提供有意义的回复”，所以我怀疑是wcf服务的原因，可能是wcf服务出错了，没有给应答。我们的wcf服务是通过调用乙方公司的C++dll接口获取数据的，C++dll又是通过调用数据库存储过程查询数据的。好的是我们的wcf服务记录了详细的日志，通过日志看到服务并没有出错，它获取到了所有数据，由此可见wcf服务应该没问题。然后我们技术老大说看看是不是协议不匹配造成的，我尝试了下重新添加了服务更新了协议，但是还是不行。接下来wcf服务的同事说这个偶尔出错的查询，正常的时候十几秒就查到结果了，出错的时候需要两三分钟才能查询到结果。原因应该就是wcf客户端获取数据超时了，但是通过查看wcf代码，默认的RecieveTimeout 是 “00:10:00”，也就是10分钟，2、3分钟不可能出错，然后能就去上网查解决办法，尝试了两三种都不行。

           这时候呢，我就想单步调试下吧，看看有没有内部异常。一调试，才发现调试的错误信息竟然是：This request operation sent to net.tcp://wcfservice.company.com:8001/MyWCFService did not receive a reply within the configured timeout (00:01:00).  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. 内部异常是null。从异常信息种我们看到需要增加上下文管道的操作超时时间，它的默认超时时间是1分钟。我们可以看到文档中的OperationTimeout 的解释“获取或设置一个时间段，操作必须在此时间段内完成否则将引发异常。”，我猜测这个时间是整着请求应答过程的超时时间，包括建立连接(OpenTimeout)、接收应答(RecieveTimeout)、关闭链接(CloseTimeout)。所以这个时间要设置的长一些，我根据自己的业务查询需求设置了15分钟this.InnerChannel.OperationTimeout = System.TimeSpan.FromMinutes(15)

 

 

         总结：

1. 同一个查询，为什么有时候十几秒返回应答，而有时候需要两三分钟，相差了十几倍，原因因该是数据库的sql优化与缓存机制。每次新查询时，数据库都比较慢，再次查询时，数据库对已经查询的存储过程sql做了优化和缓存，所以速度比第一次快了很多。

2. linux服务器的线上release版本日志中记录的异常信息为什么和本地debug调式模式下的异常信息不同。也许是linux下的dotnet代码走了不同的分支，还有待继续研究。