【问题标题】:TimeoutException when TransferMode=Streamed当 TransferMode=Streamed 时出现 TimeoutException
【发布时间】:2011-08-01 12:09:02
【问题描述】:

我继承了这个由客户端和服务器代码组成的庞大应用程序,并且我正在尝试将部分通信的传输模式更改为“流式传输”,以解决缓冲模式下可能发生的真正浪费的内存消耗和让我的客户抛出 OOM 异常,另见 this answer

代码如下:

GZipMessageEncodingBindingElement gElement = new GZipMessageEncodingBindingElement();

HttpsTransportBindingElement hElement = new HttpsTransportBindingElement();
hElement.TransferMode = TransferMode.Streamed;
hElement.MaxBufferSize = int.MaxValue;
hElement.MaxBufferPoolSize = int.MaxValue;
hElement.MaxReceivedMessageSize = int.MaxValue;

CustomBinding binding = new CustomBinding();
binding.SendTimeout = new TimeSpan(0, 0, 60);
binding.Elements.Add(gElement);
binding.Elements.Add(hElement);

EndpointAddress address = new EndpointAddress(uri);

return new ChannelFactory<T>(binding, address).CreateChannel();

异常是 TimeoutException,它建议我增加 SendTimeout(当前设置为 1 分钟)。

更新: 但是,有 2 个服务在将 transferMode 设置为流式传输后仍然有效,我实际上通过在 GZIPMessageEncoder.ReadMessage(Stream, ... )。因此,对于 2 项服务,它会在 ReadMessage 中中断,而对于一项服务,则不会。据我所知,在 ConcurrencyMode 和 InstanceContextMode 方面,服务配置相同。

更新 2: 仅配置一项似乎无法作为流式传输的服务并让其他 2 项服务处于缓冲状态后,它部分工作了。所以这不是服务本身不好,也许是某些连接在流模式下妨碍了其他连接,导致它们超时。

如果我只删除 'TransferMode' 行,一切都很好,并且测试服务器的响应时间永远不会超过一秒左右,所以仅仅增加 SendTimeout 不会有任何结果。

对于这个测试,顺便说一下,我只是改变了客户端,据我的理解,这个设置应该不会影响客户端和服务器的通信方式,只会影响具有“流式”设置的应用程序处理数据的方式。

请放轻松,我是一个完全的 WCF 新手,虽然我在 MSDN 页面上看到了一些关于流传输模式的警告,但在我的代码/配置中 grep 的指针会非常有帮助,否则它只是巨大的,许多服务,每个服务都有不同的传输设置等。

谢谢!

【问题讨论】:

    标签: c# .net wcf


    【解决方案1】:

    我无法准确找出问题的原因,但通过执行以下操作,我能够解决问题并消除过多的内存消耗等。

    摆脱 GzipMessageEncoder 后(请参阅 wcf conditional compression 了解如何用 IIS 的内置压缩替换它),这是一个怪物(请参阅我在 WCF HttpTransport: streamed vs buffered TransferMode 上的回答),很容易切换到流传输模式:@987654323 @。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2017-03-28
      • 2011-08-21
      • 2011-08-19
      • 1970-01-01
      • 1970-01-01
      • 2018-05-14
      • 1970-01-01
      相关资源
      最近更新 更多