It seems like on some RESTXQ/REST pipelining (restxq calling another restxq api) causes basex to hang. In this scenario a mock client was created to test the system. A test was written to automate mock client requests. A restxq path was created run tests. More specifically...
1) Browse to http://localhost:8984/unit-test/test where last parameter "test" maps the directiory where unit tests are located. 2) #1 is handled by a RESTXQ function where a REST URL is fetched: fetch(http://localhost:8984/rest?command=test+../webapp/mock-client/test) 3) #2 is handled by a unit-test that fetches a mock-client URL fetch(http://localhost:8984/mock-client/do-something) 4) #3 is handled by a the mock-client hitting the system fetch(http://localhost:8984/system/do-something)
- #3 and #4 (mock-client) work great - #2 (the unit-test) work great when running tests from command line OR when the test is a simple unit:assert(<canary/>). But basex hangs otherwise
Thanks for any insight on why the system calling back to itself may cause a system hang.
Hi Erik,
This thread may be relevant [1]. Have you tried client:execute in place of fetch REST?
/Andy
[1] http://www.mail-archive.com/basex-talk@mailman.uni-konstanz.de/msg08962.html
On 30 March 2017 at 22:31, Erik Peterson ep@ardec.com wrote:
It seems like on some RESTXQ/REST pipelining (restxq calling another restxq api) causes basex to hang. In this scenario a mock client was created to test the system. A test was written to automate mock client requests. A restxq path was created run tests. More specifically...
- Browse to http://localhost:8984/unit-test/test where last parameter
"test" maps the directiory where unit tests are located. 2) #1 is handled by a RESTXQ function where a REST URL is fetched: fetch(http://localhost:8984/rest?command=test+../webapp/mock-client/test) 3) #2 is handled by a unit-test that fetches a mock-client URL fetch(http://localhost:8984/mock-client/do-something) 4) #3 is handled by a the mock-client hitting the system fetch(http://localhost:8984/system/do-something)
- #3 and #4 (mock-client) work great
- #2 (the unit-test) work great when running tests from command line OR
when the test is a simple unit:assert(<canary/>). But basex hangs otherwise
Thanks for any insight on why the system calling back to itself may cause a system hang.
Unfortunately I haven't been successful with this approach either. The job just hangs in state 'running'.
On Thu, Mar 30, 2017 at 3:59 PM, Andy Bunce bunce.andy@gmail.com wrote:
Hi Erik,
This thread may be relevant [1]. Have you tried client:execute in place of fetch REST?
/Andy
[1] http://www.mail-archive.com/basex-talk@mailman.uni-konstanz.de/msg08962.html
On 30 March 2017 at 22:31, Erik Peterson ep@ardec.com wrote:
It seems like on some RESTXQ/REST pipelining (restxq calling another restxq api) causes basex to hang. In this scenario a mock client was created to test the system. A test was written to automate mock client requests. A restxq path was created run tests. More specifically...
- Browse to http://localhost:8984/unit-test/test where last parameter
"test" maps the directiory where unit tests are located. 2) #1 is handled by a RESTXQ function where a REST URL is fetched: fetch(http://localhost:8984/rest?command=test+../webapp/mock-client/test) 3) #2 is handled by a unit-test that fetches a mock-client URL fetch(http://localhost:8984/mock-client/do-something) 4) #3 is handled by a the mock-client hitting the system fetch(http://localhost:8984/system/do-something)
- #3 and #4 (mock-client) work great
- #2 (the unit-test) work great when running tests from command line OR
when the test is a simple unit:assert(<canary/>). But basex hangs otherwise
Thanks for any insight on why the system calling back to itself may cause a system hang.
basex-talk@mailman.uni-konstanz.de
-
Andy Bunce -
Erik Peterson