Hi Marco,
We haven’t experienced such a behavior by ourselves, even in very complex applications. Is the faulty behavior reproducible? Does it make a difference if you change the value of the PARSERESTXQ option [1]? And is it already the http:send-request call that returns the wrong result, or is it the actual RESTXQ function in which the http:send-request call is contained? You could additionally output the result of the function call to standard error (via fn:trace) or to a file (via file:write) and compare the output in both of your setups.
If there’s any chance to reproduce this (e.g. by creating hundreds or thousands of dummy RESTXQ functions), that’d be fine.
Cheers, Christian
[1] http://docs.basex.org/wiki/Options#PARSERESTXQ
On Thu, May 16, 2019 at 1:27 PM Marco Lettere m.lettere@gmail.com wrote:
Hello everyone,
we came accross an inconsistency which we are not able to find an explanation for and giving up after having spent on it the whole morning...
From a restxq we call an external REST service (InfluxDB) like shown in [1]. This usually works as expected returning a response forged as in [2].
When the same RESTXQ is deployed in a much more complex application (with several RESTXQ modules and REPO modules) the first call (which takes a lot of time because it incurs the initial compiling delay) returns [3] instead of [2]. From the second call onwards the result stabilizes correctly to [2].
If I call any other RESTXQ function as a sort of warm-up (spending there all the initial delay) [1] behaves correctly returning always [2].
Do you please have a clue on why this happens?
We noticed it for the first time because we started to use service jobs which cause this access pattern ...
Thanks for any help.
[1]
module namespace test = 'test';
declare %rest:path("test") %rest:GET function test:test() { let $url := "http://localhost:8086/query?pretty=false&chunked=false&db=nestway&am..." let $results := http:send-request(<http:request method="get"/>, $url) return $results };
[2]
<http:response xmlns:http="http://expath.org/ns/http-client" status="200" message="OK"> <http:header name="Transfer-Encoding" value="chunked"/> <http:header name="Connection" value="close"/> <http:header name="X-Influxdb-Version" value="1.1.1"/> <http:header name="Date" value="Thu, 16 May 2019 11:05:59 GMT"/> <http:header name="Request-Id" value="95b729c7-77ca-11e9-8065-000000000000"/> <http:header name="Content-Type" value="application/json"/> <http:body media-type="application/json"/> </http:response>
<json type="object"> <results type="array"> <_ type="object"> <series type="array"> <_ type="object"> <name>frontoffice</name> <columns type="array"> <_>time</_> <_>consumable</_> <_>customer</_> <_>guests</_> <_>type</_> <_>user</_> </columns> <values type="array"> <_ type="array"> <_>2019-05-10T21:55:00Z</_> <_>access</_> <_>c9a83ce3-c938-4677-a0df-72bc96354509</_> <_ type="number">0</_> <_>starttimer</_> <_>d50de945-23ed-4b33-84e8-8ef533a96fb7</_> </_> </values> </_> </series> </_> </results> </json>
[3]
<http:response xmlns:http="http://expath.org/ns/http-client" status="200" message="OK"> <http:header name="Transfer-Encoding" value="chunked"/> <http:header name="Connection" value="close"/> <http:header name="X-Influxdb-Version" value="1.1.1"/> <http:header name="Date" value="Thu, 16 May 2019 11:19:30 GMT"/> <http:header name="Request-Id" value="7957030a-77cc-11e9-8066-000000000000"/> <http:header name="Content-Type" value="application/json"/> <http:body media-type="application/json"/> </http:response> map { "results": [map { "series": [map { "values": [["2019-05-10T21:55:00Z", "access", "c9a83ce3-c938-4677-a0df-72bc96354509", 0.0e0, "starttimer", "d50de945-23ed-4b33-84e8-8ef533a96fb7"]], "name": "frontoffice", "columns": ["time", "consumable", "customer", "guests", "type", "user"] }] }] }