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
ChitraChitra 

Getting Soap response with Errors

Hello All,

We have an application that parses SOAP message to extract the data. From Last week, we have been having problems with Salesforce sending random characters in the Response . It is intermitten and our application crashes for about 2 - 3 hours and starts working again. So I am guessing it is not the problem with our application as it works when the response is right.

Have any one of you have seen anything like this before? I m not sure if this is the problem with the winter release.

Thanks,
Chitra
DevAngelDevAngel
If you are parsing the soap responses using your own custom code, you need to be able to handle the chunking. When a message is chunked, there is a value in the xml that is kind of like a checksum (Simon?). Also the header will contain the size of the chunk. This will occur on large querys mostly.
ChitraChitra
Thanks Dave for your response.

We are not using custom code to parse the Response - we are using axis 1.3 standard libraries. We are not using gzip compression. We set the batch size to 1500 for query (retrieving 7 fields from Accounts and 4 fields from AccountTeamMember) and this was working fine till 20th. Since then We are getting Malformed (close tag) responses. The error occurs both via the API calls and in Sforce explorer. As mentioned , for the same request , it starts working again after few hours.

The following is the excerpt from TCPMON ( this is even before it gets to axis XML parser)

G362803ff8
>

'select Id, Site, BillingPostalCode, OwnerId, ParentId, RecordTypeId, Type from Account where Deleted__c = false'
'select Id, AccountId, UserId, TeamMemberRole from AccountTeamMember'


We are always having trouble with the close tag. But at this point, we cant say for sure if it is always the "Site" element in Accounts.

Also , if this matters at all, we are using Trial account upgraded to enterprise.

Case number in salesforce :00695032

Thanks,
Chitra
SuperfellSuperfell
As Dave said, this is perfectly valid, its just HTTP/1.1 chunked encoding

<Site>G36280</Site
3ff8
>


Based on other reports i've seen, its possible that the corruption is actually being caused by TCPMON, try it without TCPMON in the picture.
ChitraChitra
Simon,

We are seeing this with or without TCPMON. We are wondering if there is a flag or configuration to handle this?

Does the load on the Salesforce server dictate if the response will be chunked/compressed? I m just curious as the same response parses fine and errors out other times.

Could you please direct me as to where I need to set/reset the flag to handle HTTP chunking.

Thanks,
Chitra
SuperfellSuperfell
supporting chunked encoding is a requirement for HTTP/1.1. If you want a non-chunked response, use HTTP/1.0 in the request.
ChitraChitra
I have no clue how to set the http version to 1.0. Should I use AXIS 1.2

I m not sure where to check. Should I set the acceptEncodingHeader to false?




Thanks,
Chitra
SuperfellSuperfell
If you're using axis, i'd recommend you switch from the default transport to CommonsHTTPSender. See the axis-user mailing list archives for details.
JohnBarnesJohnBarnes
We are already using the CommonsHTTPSender class as we initially were having trouble with socket timeouts and the persisent connections allowed us to get past that.

We just tried the application again and got the same result with the '3ff8' embedded in the Site closing tag.

We are using axis 1.3 and the CommonsHTTPSender. It is using HTTP 1.1.

Are you suggesting we find a 1.0 version of CommonsHTTPSender? If we go back to HTTP 1.0 we will lose persistent connections and may have the socket timeout issue again.

This issue began after the Winter '06 release. Even though we are using the 6.0 API could something have changed that introduced this issue? Would you reccomend us trying the 7.0 API instead with the new SOAP stack?

We have an upset client and this is a show stopper with our Acceptance Testing, do you have any ideas on what we should try?

Regards,

John
SuperfellSuperfell
the 3ff8 is a red herring, it's part of the HTTP/1.1 chunked encoding, commonsHTTP will remove these before passing the data back to the calling app.

Try capturing the problematic response with SOAPScope, (www.mindreef.com) If that shows an error, then please forward me the SOAPScope workspace so i can examine the response directly.
JohnBarnesJohnBarnes
Simon,

We have not been able to run the application using SoapScope per your suggestion. We tried this several times yesterday using different configurations. In the simplest config, were Soapscope is simply forwarding messages to salesfoce, I get a very interesting error response that content length is required in a POST. I spent some time yesterday researching this message on the Web and it seems to be related to other problems with "Transfer Encoding:
chunked " handling in the HTTP 1.1 protocol.
Interestingly, there were also other problems with Axis returning null results in similar situations with chunked encoding. I am continuing to investigate and I will try to get SioapScope traces as soon as possible.

I also tried the 7.0 version of the Partner API and I am getting the same error. The traces look a little different ( more 3ff8 in the middle of the tags ) but the result is the same.

At this point, I think it may be productive to 'hack'
CommonsHTTPSender as I am begining to suspect that it is not handling the chunked encoding properly in this case.

Any other ideas?
SuperfellSuperfell
change the URL to be http, use the network sniffer in SOAPScope, that's how i always use it, never have any problems.

Have you tried an earlier build of axis/httpCommons ? i've used Axis 1.1 with its version of HTTP commons and never seen this problem.
EnderEnder
If you are frustrated to the point of "hacking" (which is understandable), the easiest thing to do is as Simon suggested. Use Axis 1.1 with HTTP Commons. The AppExchange/Sforce Data Loader uses this, and since so many people use it, it has a high probability of working for you. And the great thing is that it is open source. So you can download the exact axis jar it uses, and its version of CommonsHttpSender already has GZIP compression for you ready to go.

http://sourceforge.net/projects/sforce-app-dl

One potential gotcha is that axis 1.1 works only with Java 1.4, unless you switch out the xml parsers bundled with 5.0 (which is a big bunch of annoyingness).

Message Edited by Ender on 02-02-2006 11:37 AM
JohnBarnesJohnBarnes
Simon,

Our support rep has the SOAPscope trace and has sent it your way. Let us know if you have any questions or need anything else. I'm hoping we can get to the bottom of this quickly as we have tried various options and can't seem to get past it.

Thanks in advance,

John
SuperfellSuperfell
As far as i can tell, this is a bug in the http/soap stack that you're using, the traces in the soapscope workspace were all fine.