Question

I inherited this huge application consisting of client and server code, and I’m trying to change the transfer mode for parts of our communication to ‘streamed’, to get around the really wasteful memory consumption that can occur in buffered mode and makes my client throw OOM exceptions, see also this answer.

The code goes something like this:

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();

And the exception is a TimeoutException that suggests I increase the SendTimeout (which currently is set to 1 minute).

Update: However, there are 2 services that still work after setting the transferMode to streamed, I actually confirmed that they use GZIP/HTTPS by setting breakpoints in GZIPMessageEncoder.ReadMessage(Stream, …). So for 2 services it breaks inside ReadMessage, for one service it doesn’t. As far is I can tell, the services are configured identically, when it comes to ConcurrencyMode and InstanceContextMode.

Update 2: After configuring only the one service that didn’t seem to work as Streamed and leaving the other 2 services buffered, it partly worked. So it is not the service as such that is bad, maybe some connection is getting in the way of other connections in Streamed mode, making them time-out.

If I delete just the ‘TransferMode’ line, everything is fine, and the test server never needs more than a second or so to respond, so just increasing the SendTimeout won’t lead anywhere.

For this test, I only changed the client btw., as to my understanding, this setting should not affect the way client and server communicate, just the way that the application with the “streamed” setting processes the data.

Please be easy on me, I’m a total WCF newb, and although I have seen some caveats on the MSDN pages about the streamed transfer mode, a pointer at what to grep for in my code / configuration would be really helpful, otherwise it’s just huge, many services, each with different transport settings etc.

Thanks!

Answer 1

I could not exactly figure out the cause of the issue, but I was able to fix the issue and getting rid of excessive memory consumption etc. by doing the following.

After getting rid of GzipMessageEncoder (see wcf conditional compression for how to replace it by IIS’ builtin compression), which is a monstrosity (see my answer on WCF HttpTransport: streamed vs buffered TransferMode), it was easy to switch to streamed TransferMode: How can I prevent BufferManager / PooledBufferManager in my WCF client app from wasting memory?.