Package gavo :: Package protocols :: Module taprunner
[frames] | no frames]

Module taprunner

source code

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.

Functions
 
normalizeTAPFormat(rawFmt) source code
 
writeResultTo(format, res, outF) source code
 
runTAPQuery(query, timeout, connection, tdsForUploads, maxrec, autoClose=True)
executes a TAP query and returns the result in a data instance.
source code
 
getQTableFromJob(parameters, jobId, queryProfile, timeout)
returns a QueryTable for a TAP job.
source code
 
runTAPJobNoState(parameters, jobId, queryProfile, timeout)
executes a TAP job defined by parameters and writes the result to the job's working directory.
source code
 
runTAPJob(jobId, queryProfile='untrustedquery')
executes a TAP job defined by parameters and job id.
source code
 
runSyncTAPJob(jobId)
executes a TAP job "synchronously".
source code
 
setINTHandler(jobId)
installs a signal handler that pushes our job to aborted on SIGINT.
source code
 
joinInterruptibly(t, jobId) source code
 
parseCommandLine() source code
 
main()
causes the execution of the job with jobId sys.argv[0].
source code
Variables
  EXIT_PLEASE = False
  __package__ = 'gavo.protocols'
Function Details

runTAPJobNoState(parameters, jobId, queryProfile, timeout)

source code 

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.

runTAPJob(jobId, queryProfile='untrustedquery')

source code 

executes a TAP job defined by parameters and job id.

This assumes the job has already been put into executing, and the apprpriate pid has been entered. To indicate that actual processing has started and the job is killable, the start time is recorded, though.

runSyncTAPJob(jobId)

source code 

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.