Addressing MaxReceivedMessageSize issues

If you’re a .NET-based consumer of Enterprise Content Services (e.g. those offered via Documentum Foundation Services) and you experience a Windows Communication Foundation CommunicationException having to do with MaxReceivedMessageSize, you may be interested in the details of this post. This post applies both to direct-to-WSDL consumers and also to consumers that leverage the DFS productivity layer for .NET. Guidance herein has more to do with WCF in general; however, it will be offered in a ECS/DFS context.

Depending on the size of incoming messages from services to your application, you may discover the need to increase the maximum received message size. For example, your application experiences the following exception raised by WCF:

System.ServiceModel.CommunicationException : The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

An example of exceeding quota could be application requests that result in data package-based responses with a large number of data objects and/or a set of data objects with significant metadata and/or content (e.g. ObjectService.get).

If you implement a direct-to-WSDL consumer of this service using Visual Studio and WCF’s Add Service Reference designer, you will by default introduce a per service binding application configuration file into the overall solution. Therefore, to declaratively increase the maximum received message size, you will edit app.config by focusing on increasing the value of the MaxReceivedMessageSize attribute on the appropriate (named) binding element from the default value in configuration as follows:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="ObjectServicePortBinding" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
        . . .
      </basicHttpBinding>
    </bindings>
    . . .
  </system.serviceModel>
  . . .
</configuration>

As in the case of a direct-to-WSDL consumer, a productivity layer-based consumer of the DFS Object service may also need to declaratively increase the value of MaxReceivedMessageSize more compatible with actual runtime requirements.

In the etc\config directory path of your local DFS SDK you should find an example App.config file. Please note that this app.config file is oriented toward productivity layer consumers, not direct-to-WSDL consumers via WCF. That being said, the same binding attributes apply to a solution here, too. The difference is how the bindings are declared in app.config.

The productivity layer oriented declaration names a single binding, DfsDefaultService, to act as the binding for all DFS services, except for DFS runtime services, which have separate, named bindings declared. So, Object service gets its (WCF- based) binding configuration from the “DfsDefaultService” binding…and so does, for example, Query service.

To declaratively increase the maximum received message size in productivity layer oriented app.config, you will most likely edit the MaxReceivedMessageSize attribute on the “DfsDefaultService” binding element from the default value in configuration as follows:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  . . .
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        . . .
        <binding name="DfsDefaultService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="1000000" maxBufferPoolSize="10000000" maxReceivedMessageSize="1000000" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <security mode="None">
            <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
            <message clientCredentialType="UserName" algorithmSuite="Default" />
          </security>
        </binding>
      </basicHttpBinding>
    </bindings>
  </system.serviceModel>
</configuration>

You may notice that the DFS SDK-based app.config binding element attribute values differ from direct-from-WCF defaults (i.e. maxBufferSize–1000000 versus 65536, maxBufferPoolSize–1000000 versus 524288, and maxReceivedMessageSize–1000000 versus 65536). This is simply a change to lessen the likelihood of encountering WCF CommunicationExceptions having to do with MaxReceivedMessageSize values.

One technique you can employ to determine what a reasonable MaxReceivedMessageSize value should be for your application is to set the value of your binding attribute/property to the absolute maximum in order to profile actual runtime message size using a web debugging proxy like Charles or Fiddler. That is, temporarily set MaxReceivedMessageSize to 2147483648 (i.e. Int32.MaxValue), pass your SOAP messages through, for example, Charles via port forwarding, review response message content length values, and reset your default runtime MaxReceivedMessageSize value accordingly.

If you prefer to take a declarative approach to WCF binding configuration for your application but you’re concerned about a user setting the value too low, you can always interrogate values at runtime in order to ensure that they’re sufficient.

For example, a productivity layer-based client could do as follows:

System.Reflection.FieldInfo appConfigInfo = typeof(ContextFactory).GetField("appConfig", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo agentServiceBindingInfo = typeof(AppConfig).GetField("m_agentServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo contextRegistryServiceBindingInfo = typeof(AppConfig).GetField("m_contextRegistryServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
System.Reflection.FieldInfo defaultServiceBindingInfo = typeof(AppConfig).GetField("m_defaultServiceBinding", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
BasicHttpBinding binding = new BasicHttpBinding();
binding.MaxReceivedMessageSize = 0x7fffffffL;
binding.MaxBufferSize = 0x7fffffffL;
agentServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);
contextRegistryServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);
defaultServiceBindingInfo.SetValue(appConfigInfo.GetValue(contextFactory), binding);

Of course, in a production app, I’d ensure that there is a log (auditable event) of such programmatic override activity. I might also consider presenting the user with a suggestion, requesting that the software be given the opportunity to auto-correct the value (e.g. updating the effective application configuration file).

-Craig
http://craigrandall.net/
@craigsmusings