Re: XML error in getLeadChanges method

Anonymous · ‎07-26-2013

I found an error querying LeadChanges from a .Net application related to XML deserialization... The error says

"The maximum string content length quota (8192) has been exceeded while reading XML data", pointing to the maxStringContentLength property.

We have been able to track at least that this error pops after trying to retrieve a specific record (works for most of the records, but there is one that causes this)

This is the app.config file in our solution

<?xml version="1.0" encoding="utf-8" ?><configuration>    <system.serviceModel>        <bindings>            <basicHttpBinding>                <binding name="MktowsApiSoapBinding" 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="Transport">                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />                        <message clientCredentialType="UserName" algorithmSuite="Default" />                    </security>                </binding>                <binding name="MktowsApiSoapBinding1" 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>        <client>            <endpoint address="https://na-sj04.marketo.com/soap/mktows/2_0"
                binding="basicHttpBinding" bindingConfiguration="MktowsApiSoapBinding"
                contract="MarketoWebService.MktowsPort" name="MktowsApiSoapPort" />        </client>    </system.serviceModel></configuration>

I tried changing the value 8192 in that property, but I still get the same error. I am wondering if this is an API limitation that can not be overriden, or if there is a way to solve it..

Any hints?

Thanks

Anonymous · ‎07-26-2013

Do you have the XML response back from our API? I'm wondering if it isn't a .Net thing vs. something in the API itself.

Anonymous · ‎07-26-2013

Thanks Erik..

I have the response, but it's a 1000 record batch so huge I am not sure I can put it here... What I did get is a more complete error message... here is what it says

{"The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 30983, position 32."}

I am not sure if this object is handled by .Net or it belongs to the marketo web service... any ideas?

Thanks

Anonymous · ‎07-26-2013

Got it. So, by my read it is your XML parser in .Net dying because of too much text. I'd do a smaller batch or see if you can chunk the response through the parser.