|
I have just happened to call a third-party webservice (cf.my other question) and the "WebClientLogFile" output shows that the request was successfully answered with a HTTP 200 OK response (within < 1 s response time). However, a few seconds later the client connection is lost with a -85 SQLCODE error because the engine crashes. This has been tested with 12.0.1.4314 and 16.0.0.2178. I'm using http, so not https/certificates are involved. What can I do to further diagnose the issue? The request's XML response should be written to an output file immediately after the web client function is called, but that step never happens. I tried with an without a keep-alive-timeout but that seems not to matter, either. |
|
Bad News/Good News Bad News: It appears to be a bug. Good News: It seems probable that you should also be able to avoid the crash by disabling WebClientLogging (ie. -zoc), in addition to removing chunky data, but you'll want to test for that. I will bring this up with development to address shortly Yes, I can confirm that: When disabling WebClientLogging, the web client function does not crash the server when using chunk mode. FWIW, from my point of view it's not really bad news in case it is a bug as there is a simple workaround available:)
(03 Feb '16, 01:12)
Volker Barth
Replies hidden
This bug was fixed in 12.0.1.4382, so I can use chunk mode with 12.0.1.4390 while using WebClientLogging - thanks!
(08 Apr '16, 11:06)
Volker Barth
|
|
Well, this is not a real answer to my question... After further testing I noticed - rather accidentally - that using CHUNK=OFF prevented the database engine from crashing while processing the web client call... create function WSF_StartRequest(XmlPayload long nvarchar)
returns xml
url 'http://...'
type 'HTTP:POST:text/xml'
header 'SOAPAction:"urn:StartRequest"'
set 'HTTP(VERSION=1.1;CHUNK=OFF)';
The request does not use chunked mode anymore (whereas so far it has done so because the contents is usually somewhat bigger than the 8196 bytes limit used with the default "AUTO" chunk setting). The response, however, does use chunked mode as before but now the engine seems to be able to handle the result accordingly. - I don't know why this makes a difference but at least it's no show-stopper anymore. This sounds like it could be a bug and something development will probably look into once it is submitted. It might be helpful to know your -xs http( ?options? )
(01 Feb '16, 14:56)
Nick Elson S...
Replies hidden
Well, I'm just using web-client functions within SQL Anywhere, not the built-in http server, so there is no -xs setting.
(02 Feb '16, 02:48)
Volker Barth
|
Are any files created in: C:\ProgramData\SQL Anywhere 17\diagnostics ?
Well, I have not yet tested with v17, but mainly with v12 and partly with v16, and there are several "crashlog" and "dmp" files for v12. For v16, there are just a few submission IDs from my current test. For v12, I have sent them via "dbsupport -sa".
Do you need any particular submission IDs?
FWIW, I had so far tested with DBISQL but the results/crashes are the same with dbisqlc.
@Mikel: I would appreciate if the crash could be diagnosed by you - please tell me if I should supply submission IDs or the like...:)
I've checked to see there are any such submissions but I don't yet see them. That could be due to a delayed refresh or something not matching the info. provide (ie. they may no longer match on the build#s shown above). Maybe you can email you client id directly to me?
Nick, I have mailed them to you, both for v12 and v16.