Thanks Jason, Carsten.
The cancel path that I see exercised is as follows:
client
-> jobManager.stopJobById(jobId)
JobManagerImpl.stopJobById(jobId):
-> this.stopJobById(jobId, true)
JobManagerImpl.stopJobById(jobId, forward):
lookup job for jobId
lookup JobQueueImpl for job topic
-> queue.stopJob(job)
JobQueueImpl.stopJob(job):
look up JobHandler for job ID
-> handler.stop()
JobHandler.stop():
this.isStopped = true
AFAICT the only state that is stored today regarding cancels in progress is the
volatile boolean isStopped flag in the JobHandler class, and this is not
accessible via the API. I don't see any other state being modified, nor do I
see any events sent.
For now I'm working around this crudely by maintaining the transitional state
information in the client. It wouldn't be too much harder to do as you
suggest, Carsten, and track that state in a service, perhaps as a decorator
around the JobManager if that's possible.
Thanks! John
________________________________
From: Jason E Bailey <[email protected]>
Sent: Saturday, August 18, 2018 4:58:45 AM
To: [email protected]
Subject: Re: Detecting whether a job has been stopped by the user but
JobExecutor hasn't terminated yet?
I believe I understand what you are looking for. It's an event that you are
look for that will indicate that the job has been requested to stop, but not
necessarily stopped.
I haven't looked at the code in question but a job should be persisting it's
state in the JCR. Whenever a change to the JOB STATUS occurs there's an OSGi
event triggered because a property has been modified.
If there was a status change to indicate that the job is in the process of
stopping that would provide two avenues of reporting. The first would be the
ability to monitor for an event that that state has been initiated, the other
would be generating a view of the jobs where it would be clear that a JOB is in
a stopping, and not yet stopped, state and you could see how long it was in
that state by the last modified time.
- Jason
On Tue, Aug 14, 2018, at 4:02 PM, John Logan wrote:
> <trying this again without the incorrect reply header...>
>
> Hi,
>
> In essence I'm trying to detect the in-progress state of a job being stopped.
>
> I see in the sling-event implementation that calling
> jobHandler.stopJobById() eventually works its way down to calling
> jobHandler.stop(), setting a flag in the JobHandler.
>
> The JobExecutor is responsible for calling
> jobExecutionContext.isStopped(), and if it returns true, the JobExecutor
> should clean up, call and exit.
>
> There might be some time elapsed between the request to stop and the
> JobExecutor returning the JobExecutionResult that updates job state. Is
> there a way to detect this interim condition via sling-event-api? I had
> a look at the code and didn't see anything obvious.
>
> What I'm trying to do is indicate in my UI that a job is being
> cancelled, but cancellation isn't complete yet.
>
> Thanks! John
