0

I have a main Thread which is a Rest Endpoint. I spawn a new Runnable in that end point and pass to the Executor service. I make the main Thread wait on my Runnable by calling join() method. Then in the run() method of my Runnable, i run a Quartz job using the Quartz Scheduler. Now this Quartz job runs in a separate thread.

However my problem is that even after the Job has finished executed and is also deleted by the Scheduler, the Main Thread is still waiting on the Runnable and the main execution starts after some 40 to 50 seconds after the Job has finished execution.

I want to terminate the Runnable Thread immediately after the Job has finished execution. How can i acheive this ?

Also immediately after the Job has been scheduled, the last line of run() method of Runnable is executed.

VinodKhade
  • 147
  • 1
  • 2
  • 10

1 Answers1

0

Resolved the issue by making the main thread wait on a boolean flag as true in a while loop. Then made the flag false when the job execution was completed in the JobListener. In the jobWasExecuted() method of the Listener, flag was set to false.

Tried using interrupt() and stop() in the JobListener as well.

But i guess the Quartz Thread was locking on The Runnable Thread in which it was executing the Job. And probably thats why the delay of 40 to 50 seconds was there even after the Job execution was completed.

Also, i am using a @Transient variable in my Job object. And each job has its own Thread, so volatile is not needed.

VinodKhade
  • 147
  • 1
  • 2
  • 10
  • 1
    Note that such a flag has to be `volatile` and you should also use `interrupt()` to tell the thread to check it. Also note that this will not be _instantly_ and the thread could disrespect the request. So I am not sure this meets the requirements you set up in your question. – Zabuzard Sep 04 '20 at 08:19
  • @Zabuzard - Thank You for the suggestions. I have updated the answer. Please check. – VinodKhade Sep 04 '20 at 08:25
  • `volatile` is needed if you set the variable from a different thread. So if you call this `stop()` method from a different thread than the actual job is running on. Otherwise the job might not observe the change and still believe the flag did not change due to internal thread caching. Hard to verify if you did not share any code though. – Zabuzard Sep 04 '20 at 08:39
  • 'making the main thread wait on a boolean flag as true in a while loop' well, that's one core wasted on polling:( – Martin James Sep 05 '20 at 09:15