[278] in Athena_Backup_System
Re: src/slave/slave_int.c: abs_abort_job_1_svc
daemon@ATHENA.MIT.EDU (delgado@MIT.EDU)
Thu Jun 27 09:47:40 1996
From: delgado@MIT.EDU
To: Bill Cattey <wdc@MIT.EDU>
Cc: delgado@MIT.EDU, athena-backup@MIT.EDU
In-Reply-To: Your message of "Wed, 26 Jun 1996 18:31:59 EDT."
<EloPdTsGgE6e1p93w0@mit.edu>
Date: Thu, 27 Jun 1996 09:47:28 EDT
The way cancellation works now is:
Admin/operator specifies they want to cancel a runnning job
using the ui.
The ui issues a manage_job call to the master specifying
"ABS_JOB_ABORT" with the job id. The Master sets the job's
state to cancelled and the call returns.
When a service request for abs_job_attention_1_svc,
abs_validate_media_1_svc, abs_job_status_1_svc from a slave
comes in through the ABS_SLAVEINT interface, the Master checks
the state of the job and if its state is "cancelled", then the Master
returns "ABS_JOB_CANCELED" to the Slave. At this time, the
Master deletes the job information from the queue. (We don't
delete the job from the queue until the slave has picked up
the cancellation notice.)
When the Slave receives "ABS_JOB_CANCELED" as a return code
for the ABS_SLAVEINT calls, it will then stop its work at
the next convenient point. This is why we specify the
caveat that current job cancellation is neither immediate
nor guaranteed. It does, however happen to work most of the
time :-).
The purpose of abs_abort_job_1_svc in the ABSSLAVE interface
is currently a place holder for future functionality. We
need to be able to have a separate thread to handle the
cancelation requests while jobs are running. (Remeber once
the slave is handling a request it stays in that service
routine until the work is completed. When it exits the
service routine, the rpc library will take the next call
request from the queue and the slave will then execute that
request, ... We currently have no way to remotely interrupt the
service call while it is running using the ABSSLAVE RPC routines
with a single-threaded process.)