Hi Christian, I'll try to answer your questions inline ...
On 16/05/19 19:38, Christian Grün wrote:
Hi Marco,
We haven’t experienced such a behavior by ourselves, even in very complex applications. Is the faulty behavior reproducible?
Only with the exact configuration of our current applciation...
Does it make a difference if you change the value of the PARSERESTXQ option [1]?
No, it doesn't. we tried higher values (wrt the default 3) and also 0 and -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?
The http:send-request returns the second element of the response in map format. We discovered it actually because a following XPath expression raised an error because it hit a map instead of a document as expected...
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.
We did all sort of tests and it's the http:send-request without doubts that already returns a map...
If there’s any chance to reproduce this (e.g. by creating hundreds or thousands of dummy RESTXQ functions), that’d be fine.
I've tried to generate #FILES * #FUNCT number of RESTXQS with increasing number of files and functions (up to OOM exceptions with default -Xms=2G) but I'm unable to reproduce... [A][B]
So I suspect that the problem might be in he file structure .... we use softlinks to hook up restxq folders, a REPO full of implementation modules so may be the resolution of all this relations might be the issue?
Clueless at the moment ...
M.
[A] python script to generate extra RESTXQS
#!/bin/python3 FILES = 100 RESTXQS = 1000
qtempl = open("template.txt").read()
for f in range(FILES): outf = open("file" + str(f) + ".xqm", "w") qout = 'module namespace _ = "urn:dummy:' + str(f) + '";\n\n'; for q in range(RESTXQS): qout += "\n" + qtempl.format(path=(str(f)+"_"+str(q))) outf.write(qout)
[B] template query stored in template.txt
declare %rest:path("test/{path}") %rest:GET function _:f{path}() {{ "{path}" }};
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"] }] }] }