This is the function I use to get data from a webservice, in SQL Anywhere v.12.0.1.3436:
Calling it I get error:
And this is what I get in the log file (sensitive data is replaced with ***, sorry for that):
As you can see, the response result is truncated some why to 1024 characters, I contacted the webservice maintainers and they confirmed that they send out the full response, I tried the same request (evelope generated by SA) in SoapUI and in C# and got correct results, no truncation, so I am prety sure the problem is somewhere within SQL Anywhere, any ideas where? Update: Updated to v.12.0.1.4085, now I get the following error:
And log now looks even worse:
After testing I rolled back to version 12.0.1.3895 and now I am back to error described at the top of this long post. |
This issue has been fixed in CR #764411, with the following builds: v16.0.1925, v12.0.1.4119, v11.0.1.3156 (or higher). The problem was not one of truncation (although this is a symptom) but rather with the way the response from the server was sent back to SQL Anywhere: if the first few bytes of the response was split across two or more packets (which is very rare and, frankly, quite odd that it would even happen) then the response would be rejected. Mark, could you share a CR number (in case it already has a public one)?
(23 May '14, 03:30)
Volker Barth
Replies hidden
Jeff added the number. Thanks Jeff!
(23 May '14, 09:38)
Mark Culp
|
After reading the What impact will the switch to OpenSSL have on SQL Anywhere strong encryption? I once again updated to latest EBF 12.0.1.4085, got a new root certificate for web service from www.geotrust.com and now TLS handshake succeeded and I got the full response, no truncation! However SA11 does not has this problem fixed, tried latest EBF 11.0.1.3113 with no luck, more about that in a separate post. Update: SA11 fixed. Glad you got it working? Is there any hint in the EBF's readme that may explain the previous truncation/timeout? FWIW, you may accept your own answer to show the "case is closed":)
(01 Apr '14, 04:57)
Volker Barth
Replies hidden
Problem still persists in SA11, So I'd like to somehow mark it as a partial answer :)
(01 Apr '14, 06:05)
Valdas
Please post a new question for the SA11 symptom.
(01 Apr '14, 07:58)
Breck Carter
Ok, I did that.
(02 Apr '14, 06:52)
Valdas
|
What part is truncated to 1024 characters? The third last line is 859 characters long, the whole posted text is longer than 1024. (maybe it is a limitation of this forum software)
Have you solved or explained this message? External environment failed to start and establish a connection within the 45 second timeout SQLCODE=-1556, ODBC 3 State="HY000"
Is this correct? Content-Length: 1203439
Part from [connid = 15, 03/31 11:38:44.792, RESPONSE] to [connid = 15, Protocol Error], is exactly 1024 characters long. At first I thought it was the logs drawback, but various other webservices, like HTTP:GET, log the whole response without problem, however I never tested with such big data chunks, 100k at most.
Yes, I solved the mentioned problem, it was my mistake, i declared incorrect external name.
Content length may vary depending on time the request is done, at the moment it is 1203463, so yes, the amount of data is huge, but as mentioned before SoapUI and C# manage it just fine.
Just to understand: Does the cited error message still appear after you have solved the external name issue? Or do you get a different error message now?
Just to add: 12.0.1.3436 is a rather old EBF, you may try with a newer EBF... (No, I do not claim that this will solve the issue, I just don't know.)
I am very sorry, I supplied wrong error message in description, the correct one:
External name mistake has nothing to do with this issue, in this situation no external stuff is used, SOAP header is generated by SA, request is done by SA, response received and logged by SA, using "third party" function is a back up plan :)
Regarding EBF, I tried same procedure on SA16, and there I get new error: The secure connection to the remote host failed: The TLS handshake failed, error code 0 SQLCODE=-990, ODBC 3 State="HY000" and this time there is no XML(Envelope) in request at all, but I think this is different story, our clients work with SA12 and are not ready to migrate anyway.
Also tried on SA11, got identical results to SA12.
A few minutes ago updated to version 12.0.1.4085, got similar results to SA16, updated the issue description.
Do you use HTTPS? In that case, v16 and newer v12.0.1 builds may show a different behaviour because the crypto lib has changed, cf. that question What impact will the switch to OpenSSL have on SQL Anywhere strong encryption?. - Note, that's a very very wild guess - you may just test with an EBF before 12.0.1.3994...
Yes, web service uses HTTPS connection, but we do not use FIPS or MobiLink.
Anyway I rolled back to EBF 12.0.1.3895 so now again I get a perfectly valid <soap-env:envelope>...</soap-env:envelope> in request and get truncated response.