Detecting whether a job has been stopped by the user but JobExecutor hasn't terminated yet?

[John Logan <Jo...@texture.com>]

<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

Re: Detecting whether a job has been stopped by the user but JobExecutor hasn't terminated yet?

[John Logan <Jo...@texture.com>]

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 <je...@apache.org>
Sent: Saturday, August 18, 2018 4:58:45 AM
To: users@sling.apache.org
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

Re: Detecting whether a job has been stopped by the user but JobExecutor hasn't terminated yet?

[Jason E Bailey <je...@apache.org>]

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