2

我们一直在客户站点看到随机的 OutOfMemoryExceptions 和 InsufficientMemoryExceptions。我们使用 GZipMessageEncoder 来压缩消息。（我知道IIS 7.x 压缩选项以及缓冲和/或 GZipMessageEncoder 的其他问题。）

我想尝试启用 WCF 流。我们的 WCF 服务具有如下合同：

[OperationContract]     
DataSet GetDataSet(Guid someGUID, string someName, DataSet parameters);

根据MSDN 上的这篇文章：

流式传输中发生的操作最多可以有一个输入或输出参数

显然，我们的合约违反了 WCF 流的限制。该合约有 3 个输入参数。

但是，出于好奇，我还是决定尝试启用流媒体。我编辑了 web.config 文件和 MyCSharpClient.config 文件，并将以下属性插入到绑定的传输部分：

<httpTransport ... transferMode="Streamed">

令我惊讶的是，一切似乎都正常工作！没有抛出异常。我可以闯入 GZipMessageEncoder 并验证是否正在调用流方法而不是缓冲区方法。

所以，我的问题是：为什么我能够在违反 WCF 输入参数限制的操作上下文上设置流传输？鉴于 MSDN 流媒体文章的措辞强硬，我认为这只是一个实现细节，我绝不能依赖这种行为。

4

1 回答 1

2

当前发生的情况如下：您在 HTTP 传输上启用了流式传输，因此传输不会缓冲任何内容 - 传输接收一个Message对象，并将其直接写入传输流（包装在 XML 编写器中）。但是，操作的参数在它们被序列化之前被缓冲，因此您正在“支付”您将传输模式设置为“缓冲”的内存使用量。在线上，不同之处在于来自该服务的响应，而不是 Content-Length 标头，将被分块（即，它将有一个Transfer-Encoded: chunked标头，并且正文将被相应地格式化。但它的工作方式就像好。

我想说 MSDN 中的文章可以选择更好的词。为了使操作能够利用流式传输，它需要有一个参数，通常是 type Stream，Message或者是实现的某种类型IXmlSerializable。但是一个简单的合同（即[OperationContract] int Add(int x, int y)）也可以工作。而且我想它会继续这样工作，因为对于一个单一的合同来说，具有“正常”操作和利用流式传输的操作是完全有效的，并且因为需要为每个端点设置传输模式（并且不是每个操作），它也必须适用于“简单”操作。

于 2012-06-12T04:10:53.910 回答