Closed mitar closed 7 years ago
It immediately cancels the job on the server only. The running job's worker is then notified when it attempts one of the following calls (those valid on a 'running'
job): job.log()
, job.progress()
, job.done()
or job.fail()
. One of the benefits of long-running jobs calling job.progress()
and/or job.log()
pretty frequently is that this is the mechanism used to notify them if the job has been cancelled/removed from the server. If one of those calls fails, the proper worker behavior (in most cases) is probably to stop working on the job, because it means that either the job is no longer running on the server, or the server is down or unreachable. The proper behavior in the latter cases is more debatable, but there are other ways to distinguish among them (e.g. calling job.getJob()
)
But those four functions can "fail" by returning a false
, but also by throwing an exception, if I am not mistaken. How I am feeling is that it is probably easiest to just turn false
into an exception and this is it. This will then effectively terminate the job.
No, job collection should never throw an exception except for truly unrecoverable errors, for example providing invalid parameters to a method call.
Thanks!
It seems you can cancel a running job. But what exactly does this do? It does not really force running code to stop?