Execution of UWS (right now, TAP only) requests.
This mainly intended to be exec’d (through some wrapper) by the queue runner in the main server thread. The jobs executed have to be in the database and have to have a job directory.
Primarily for testing an alternative interface rabRun exists that takes that takes jobid, and parameters.
The tap runner takes the job to EXECUTING shortly before sending the query to the DB server. When done, the job’s state is one of COMPLETED, ABORTED or ERROR.
getQTableFromJob(parameters, job, queryProfile, timeout)[source]¶
returns a QueryTable for a TAP job.
executes a TAP job synchronously.
When this is done, the job will be in an end state, i.e., ERROR, COMPLETED or perhaps ABORTED.
You must call tap.WORKER_SYSTEM.destroy(jobId) when done yourself.
Essentially, this puts the job into EXECUTING and declares the pid as -1. The UWS machinery will happily kill a job with a pid when asked to abort such a job, and since sync jobs run with the server’s pid, that’s really not what we want (conversely: sync jobs can’t really be aborted). Anyway: Do not put anything getpid returns into a sync job’s pid field.
executes a TAP job defined by parameters and job id.
This assumes the job has already been put into executing, and the appropriate pid has been entered. To indicate that actual processing has started and the job is killable, the start time is recorded, though.
runTAPJobNoState(parameters, jobId, queryProfile, timeout)[source]¶
executes a TAP job defined by parameters and writes the result to the job’s working directory.
This does not do state management. Use runTAPJob if you need it.
installs a signal handler that pushes our job to aborted on SIGINT.