function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
SolomonSolomon 

Inconsistent Error between Environments

The issue we are encountering in that when making an HTTP Request, we immediately receive an System.CalloutException: Exceeded max size limit of 3000000. This issue is not occurring with the same code in the org's sandbox. In the sandbox, the call is successful and returns data as expected. But in the production instance, we constantly receive this error. I have checked the heap size prior to making the callout and it is 5406 bytes in size, well within the 3MB size limit. This is being reported in both the sandbox and in production. All other governor limits are well within limits. There are two HTTP requests that are made before the call that causes the error (to authenticate, etc.) so it is very confusing why this error is occurring, especially since it works just fine in the sandbox.

Please help.
Best Answer chosen by Solomon
KevinPKevinP
is your response bigger than 3mb? that could cause it. 

All Answers

KevinPKevinP
what data is being transmitted by the call? could it be that the data size in production is much larger than the data size in sandbox?
SolomonSolomon
The error is being caused by the HTTP request being to big. The call never makes it out to request that data.   According to http://www.salesforce.com/us/developer/docs/dbcom_apex250/Content/apex_gov_limits.htm

Maximum size of callout request or response (HTTP request or Web services call)    3 MB

But we know for a fact that the actual request is 5406 bytes. We don't know what is causing the production org to think the request is bigger then 3 MB. 
 
KevinPKevinP
Right. To be clear I was asking if that callout is POST or GET based. If POST, then is the post data bigger than 3mb? If get, is the url params string too big? --  Kevin Poorman Sent with Airmail
SolomonSolomon
Its a get. No the Url is about 200 character long.  The body is zero. 
KevinPKevinP
Can you post your code? --  Kevin Poorman Sent with Airmail
SolomonSolomon
Forgive me if this is the wrong bit, I am the SF admin and I am working with a non-SF dev, and they are out of office.  

I believe this is the point that is causing the issue.  I've seen the request that is supposed to be sent, it is nothing more then a URL.  Kevin can that error be caused by the response to the request without ever registering that the request actully suceeded?  I only ask becasue I know the 3 MB limit is both request and respone.

public HttpResponse send() {
            generateEndpoint();
            generateBody();
            if( logDetails() ) {
                System.debug( 'Generated Endpoint: ' + request.getEndpoint() );
                System.debug( 'Generated Body: ' + request.getBody() );
                System.debug( 'Body Length: ' + request.getBody().length());
                System.debug ( 'Heap Size: ' + Limits.getHeapSize());
            }
            response = session.http.send( request );
            if( logDetails() ) {
                System.debug( 'Response Status: ' + response.getStatusCode() );
                String body = response.getBody();
                System.debug( 'Response Body: ' + body );
                if( body.length() > 1000 ) {
                    body = body.left( 1000 );
                }
                System.debug( 'First 1000 chars of Response Body: ' + body );
            }
            return response;
KevinPKevinP
is your response bigger than 3mb? that could cause it. 
This was selected as the best answer
SolomonSolomon
How would I check if a response had been send back?
SolomonSolomon
Found out the cause.  With the launch of Spring '15  the logging in the developer console was improved.  It allowed us to identify that it was actully the reposne that was causing the issue.  We then had the ablity to know the size and then break the respones down into a managable size.