Error: The maximum message size quota for incoming messages (65536) has been exceeded in Model Viewer

Topics: Technical Questions
Jan 20, 2010 at 12:05 AM
Edited Jan 20, 2010 at 12:09 AM

Hi,

I've been trialing MSE, and had used the test services that came in the samples, and I was now in the stage where I was going to trial it with our existing services, which have real data contracts and services. As I did this and restarted the model viewer on my next day of work I noticed the following exception in the log file:

 MseAdmin-DataCache: Unexpected exception 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. --->
System.ServiceModel.QuotaExceededException: 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.
--- End of inner exception stack trace ---

Server stack trace:
at System.ServiceModel.Channels.ClientDuplexConnectionReader.DecodeMessage(Byte[] buffer, Int32& offset, Int32& size, Boolean& isAtEOF,
TimeSpan timeout)
at System.ServiceModel.Channels.SessionConnectionReader.DecodeMessage(TimeSpan timeout)
at System.ServiceModel.Channels.SessionConnectionReader.Receive(TimeSpan timeout)
at System.ServiceModel.Channels.SynchronizedMessageSource.Receive(TimeSpan timeout)
at System.ServiceModel.Channels.FramingDuplexSessionChannel.Receive(TimeSpan timeout)
at System.ServiceModel.Channels.FramingDuplexSessionChannel.TryReceive(TimeSpan timeout, Message& message)
at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation,
Object[] ins, Object[]
outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall,
ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.MSE.Tools.ModelViewer.SCProxy.ServiceModel.GetSchema(Guid ID)
at Microsoft.MSE.Tools.ModelViewer.SCProxy.ServiceModelClient.GetSchema(Guid ID)
at Microsoft.MSE.Tools.ModelViewer.SCDAL.BaseHash`2.LoadItems()

To fix this exception I proceeded to change in Microsoft.MSE.Tools.ModelViewer.exe.config the default values for maxBufferSize, maxBufferPoolSize and maxReceivedMessageSize 65536 for all the bindings: 

<binding name="BasicHttpBinding_ServiceModel" 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="">
</transport>
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>

To 2147483647:

<binding name="BasicHttpBinding_ServiceModel" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
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="">
</transport>
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>

Two questions:

1. Any clues on the reason? Are there some limits I should have in consideration? (max number of services, data contracts, depth of children in the data contracts, etc.)

2. What are the max recommended values?

Thanks.

Jan 20, 2010 at 3:25 AM

Hi,

You have changed the message size at the wrong place. You need to change the same on associated binding on the end point. This can be done using the Model Viewer.

1. Open the model Viewer.

2. Switch to the Binding Managment View.

3. Double click on the Binding that you have associated with the endpoint and change the attribute "maxReceivedMessageSize"  there.

4. Click Apply once done.

Note : please set the maxReceivedMessageSize depending on the size of the message that you expect the MSE to handle, instead of giving a very large value. This would impact the Performance.

Now you can try yo send the large message size.

 

Let me know if you want more info.

Thanks.

Jan 21, 2010 at 1:24 AM

Hi Makuma, that's nice to know for the messages them selves. This is actually between the model viewer and the MSE services. The exception happened as I double clicked the virtual method inside the MSE model viewer console. What was happening was that on this action, the MSE woudn;t show any info on the virtual method, and it would disconnect from the catalog.

Developer
Jan 21, 2010 at 4:19 AM

The appropriate maxRecievedMessageSize and maxBufferSize will be dependent upon several factors including the number of endpoints, operations and versions, resources, etc. But typically the most significantly factor is the size of your schemas and data entities.    As such, there aren't really any specific recommended values other than just saying use numbers large enough to meet your needs.  The good thing is that having large values for these properties won't have a material impact on the Model Viewer.  Having 100's of operations and resources will introduce more of a managability problem within the tool more than anything else... and using the grouping feature can help aleviate that problem.