0 votes
865 views

Hi,

I'm trying to access the async TAP service by submitting the following query via a POST request:

https://datalab.noao.edu/tap/async?request=doQuery&lang=ADQL&format=csv&query=select+TOP+100+*+from+allwise.source&phase=RUN

The TAP service returns the below xml. It appears that the job always stays in the PENDING phase and is never really executed.
What am I doing wrong? Any help would be highly appreciated!

<?xml version="1.0" encoding="UTF-8"?>
<uws:job xmlns:uws="http://www.ivoa.net/xml/UWS/v1.0" xmlns:xlink="http://www.w3.org/1999/xlink">
  <uws:jobId>hc9qhl4rzadjao49</uws:jobId>
  <uws:runId />
  <uws:ownerId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" />
  <uws:phase>PENDING</uws:phase>
  <uws:quote>2021-03-20T13:59:58.078</uws:quote>
  <uws:startTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" />
  <uws:endTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" />
  <uws:executionDuration>3600</uws:executionDuration>
  <uws:destruction>2021-03-27T12:59:58.077</uws:destruction>
  <uws:parameters />
  <uws:results />
</uws:job>

by frakiw (170 points) | 865 views

1 Answer

0 votes
Best answer
TAP queries follow the UWS (Universal Worker Service, see https://ivoa.net/documents/UWS) pattern for job control, so your initial POST only creates the job and then returns the jobID.  To set the job running you need to explicitly call the job 'phase' endpoint, e.g. using your example

curl -X POST -d "PHASE=RUN" -o - https://datalab.noao.edu/tap/async/hc9qhl4rzadjao49/phase

would set the job phase to run.  Without any arguments you would call that endpoint to check on the status and then similarly call the /results or /error endpoints to retrieve the results or error messages respectively.  Each call has to use the jobid.

Note the queryClient interface handles these details for you, feel free to write back if you have questions about that or see the documentation on the web page.
by datalab (20.7k points)
selected by 743
According to the UWS documentation (see below "2.2.3.1. Creating a Job") it is also possible for the inital POST to specifiy a phase=RUN parameter to set the job immediately into a potentially running state, and thus avoiding to explicitly call the job 'phase' endpoint. VizieR and IRSA are using this feature in their implementations which makes the job submission a bit more convenient.

After having explicitly called the job 'phase' endpoint (via a POST with phase=RUN), I get a http response code of 405 (Method Not Allowed).

I've tried exactly the same with VizieR an IRSA asynch TAP services and everything works fine there! So, this doesn't seem to be an issue related to the correct use of the UWS pattern.

1)
https://datalab.noao.edu/tap/async?request=doQuery&lang=ADQL&format=csv&query=select+TOP+100+*+from+allwise.source

<?xml version="1.0" encoding="UTF-8"?>
<uws:job xmlns:uws="http://www.ivoa.net/xml/UWS/v1.0" xmlns:xlink="http://www.w3.org/1999/xlink">
  <uws:jobId>xcnmm54doe1yczj5</uws:jobId>
  <uws:runId />
  <uws:ownerId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" />
  <uws:phase>PENDING</uws:phase>
  <uws:quote>2021-03-23T10:18:27.135</uws:quote>
  <uws:startTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" />
  <uws:endTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" />
  <uws:executionDuration>3600</uws:executionDuration>
  <uws:destruction>2021-03-30T09:18:27.135</uws:destruction>
  <uws:parameters />
  <uws:results />
</uws:job>

2)
https://datalab.noao.edu/tap/async/xcnmm54doe1yczj5/phase?phase=RUN
-> 405 (Method Not Allowed)


2.2.3.1. Creating a Job

POSTing a request to the Job List creates a new job (unless the service rejects the request). The response when a job is accepted must have code 303 “See other” and the Location header of the response must point to the created job. The response when the job is rejected should be a HTTP 403 Forbidden status style response.

This initial POST will in most cases carry parameters for the protocol that is using the UWS pattern, as detailed in 4 .In addition for the initial post may contain job control parameters if allowed by the implementing protocol (i.e. if UWS job control parameter names do not clash with the implementing protocol parameters). One use of this facility might be to have the job placed into a potentially running state by adding ?PHASE=RUN query part to the job creation URL.
Setting the PHASE=RUN when the job is submitted is optional in the UWS spec and apparently not implemented in our TAP service.

The 405 message you get when explicitly setting the job state usually means you used GET instead of POST for the service call.  A GET on the /phase endpoint is used to retrieve the job status (at least, in our implementation).
Could you explain why the initial post works fine (200 OK), while the second post to explicitly set the job state fails with a HTTP response code of 405.
I'm using exactly the same code for both posts, so I don't understand why I get a 405.
The HTTP method is correct, it's a POST !
I finally got this running using a different http API !
One issue also was PHASE=RUN has to be uppercase. I used phase=RUN which didn't work.
Thanks for your help!

414 questions

430 answers

436 comments

635 users

Welcome to Data Lab Help Desk, where you can ask questions and receive answers from other members of the community.

Categories