I am hosting a WCF service in IIS using basicHttpBinding. The WCF web services queries back end SQL Server 2008 by using ADO.Net and return a DataTable to client side of WCF
George, be sure to look in the event log when things like this happen. See if WCF or any other component has logged an error.
Also, try turning on WCF tracing and see whether there's an internal error that's not being logged somehow. You may need to make the trace verbose in order to see it, but take a look and see what's there.
Just because you get an obscure error from IIS, doesn't mean there's not more and better information available somewhere. After all, the error message did say, "See server logs for more details."
There's a multitude of buffer sizes you can play with - they are kept fairly small (64K) by default in order to avoid Denial-of-service attacks, but if you need to, you can increase those:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="largebuffers" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
bypassProxyOnLocal="false" transactionFlow="false"
hostNameComparisonMode="StrongWildcard"
maxBufferSize="524288" maxBufferPoolSize="524288"
maxReceivedMessageSize="65536"
messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
allowCookies="false">
<readerQuotas maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384" maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
</binding>
</basicHttpBinding>
</bindings>
Have a look at the "MaxBufferSize", "MaxBufferPoolSize", "MaxReceivedMessageSize" settingsin the binding, as well as the various settings in the <readerQuotas>
section.
I would try to just increase the "MaxBufferSize" and "MaxBufferPoolSize" first and see if that alone helps - most of the other settings should really be more geared towards when the service receives and needs to process a message.
There are no hard limits as to how big an object can be that you serialize back. However, the DataTable does carry a significant overhead, and if you don't really need that DataTable functionality on the client side, you might also do a conversion on the server to send back just a collection or generic list of objects - instead of the heavy-lift DataTable object.
Furthermore, if you frequently send back large amounts of data, you might need to investigate the streaming capabilities of WCF, too (e.g. if you return pictures, videos, that kind of stuff). Marc
Maybe will be helpful for someone.
I had the same error. It was solved by setting MaxItemsInObjectGraph property (to big value) in server-side web.config:
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceBehavior">
<dataContractSerializer maxItemsInObjectGraph="100000"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServiceBehavior" name="Company.MyService">
<!-- etc -->
</service>
</services>
got it from here: http://forums.asp.net/post/4948029.aspx
refer the following code snippet ..
<bindings>
<netTcpBinding>
<binding name="ECMSBindingConfig" closeTimeout="00:10:00" openTimeout="00:10:00"
sendTimeout="00:10:00" maxBufferPoolSize="2147483647" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647" portSharingEnabled="true">
<readerQuotas maxArrayLength="2147483647" maxNameTableCharCount="2147483647"
maxStringContentLength="2147483647" maxDepth="2147483647"
maxBytesPerRead="2147483647" />
<security mode="None" />
</binding>
</netTcpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="ECMSServiceBehavior">
<dataContractSerializer ignoreExtensionDataObject="true" maxItemsInObjectGraph="2147483647" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceTimeouts transactionTimeout="00:10:00" />
<serviceThrottling maxConcurrentCalls="200" maxConcurrentSessions="100"
maxConcurrentInstances="100" />
</behavior>
</serviceBehaviors>
</behaviors>