How to check if scheduled Quartz cron job is running or not? Is there any API to do the checking?
scheduler.getCurrentlyExecutingJobs() should work in most case. But remember not to use it in Job class, for it use ExecutingJobsManager(a JobListener) to put the running job to a HashMap, which run before the job class, so use this method to check job is running will definitely return true. One simple approach is to check that fire times are different:
public static boolean isJobRunning(JobExecutionContext ctx, String jobName, String groupName)
throws SchedulerException {
List<JobExecutionContext> currentJobs = ctx.getScheduler().getCurrentlyExecutingJobs();
for (JobExecutionContext jobCtx : currentJobs) {
String thisJobName = jobCtx.getJobDetail().getKey().getName();
String thisGroupName = jobCtx.getJobDetail().getKey().getGroup();
if (jobName.equalsIgnoreCase(thisJobName) && groupName.equalsIgnoreCase(thisGroupName)
&& !jobCtx.getFireTime().equals(ctx.getFireTime())) {
return true;
}
}
return false;
}
Also notice that this method is not cluster aware. That is, it will only return Jobs currently executing in this Scheduler instance, not across the entire cluster. If you run Quartz in a cluster, it will not work properly.
If you notice in the QUARTZ_TRIGGERS table, there is a TRIGGER_STATE column. This tells you the state of the trigger (TriggerState) for a particular job. In all likelihood your app doesn't have a direct interface to this table but the quartz scheduler does and you can check the state this way:
private Boolean isJobPaused(String jobName) throws SchedulerException {
JobKey jobKey = new JobKey(jobName);
JobDetail jobDetail = scheduler.getJobDetail(jobKey);
List<? extends Trigger> triggers = scheduler.getTriggersOfJob(jobDetail.getKey());
for (Trigger trigger : triggers) {
TriggerState triggerState = scheduler.getTriggerState(trigger.getKey());
if (TriggerState.PAUSED.equals(triggerState)) {
return true;
}
}
return false;
}
Have you looked at this answer? Try with:
scheduler.getCurrentlyExecutingJobs()
Related
I'm using quartz-scheduler 1.8.5. I've created a Job implementing StatefulJob. I schedule the job using a SimpleTrigger and StdSchedulerFactory.
It seems that I have to update the Trigger's JobDataMap in addition to the JobDetail's JobDataMap in order to change the JobDataMap from inside the Job. I'm trying to understand why it's necessary to update both? I noticed that the JobDataMap is set to dirty. Maybe I have to explicitly save it or something?
I'm thinking I'll have to dig into the source code of Quartz to really understand what is going on here, but I figured I'd be lazy and ask first. Thanks for any insight into the inner workings of JobDataMap!
Here's my job:
public class HelloJob implements StatefulJob {
public HelloJob() {
}
public void execute(JobExecutionContext context)
throws JobExecutionException {
int count = context.getMergedJobDataMap().getInt("count");
int count2 = context.getJobDetail().getJobDataMap().getInt("count");
//int count3 = context.getTrigger().getJobDataMap().getInt("count");
System.err.println("HelloJob is executing. Count: '"+count+"', "+count2+"'");
//The count only gets updated if I updated both the Trigger and
// JobDetail DataMaps. If I only update the JobDetail, it doesn't persist.
context.getTrigger().getJobDataMap().put("count", count++);
context.getJobDetail().getJobDataMap().put("count", count++);
//This has no effect inside the job, but it works outside the job
try {
context.getScheduler().addJob(context.getJobDetail(), true);
} catch (SchedulerException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
//These don't seem to persist between jobs
//context.put("count", count++);
//context.getMergedJobDataMap().put("count", count++);
}
}
Here's how I'm scheduling the job:
try {
// define the job and tie it to our HelloJob class
JobDetail job = new JobDetail(JOB_NAME, JOB_GROUP_NAME,
HelloJob.class);
job.getJobDataMap().put("count", 1);
// Trigger the job to run now, and every so often
Trigger trigger = new SimpleTrigger("myTrigger", "group1",
SimpleTrigger.REPEAT_INDEFINITELY, howOften);
// Tell quartz to schedule the job using our trigger
sched.scheduleJob(job, trigger);
return job;
} catch (SchedulerException e) {
throw e;
}
Update:
Seems that I have to put the value into the JobDetail's JobDataMap twice to get it to persist, this works:
public class HelloJob implements StatefulJob {
public HelloJob() {
}
public void execute(JobExecutionContext context)
throws JobExecutionException {
int count = (Integer) context.getMergedJobDataMap().get("count");
System.err.println("HelloJob is executing. Count: '"+count+"', and is the job stateful? "+context.getJobDetail().isStateful());
context.getJobDetail().getJobDataMap().put("count", count++);
context.getJobDetail().getJobDataMap().put("count", count++);
}
}
This seems like a bug, maybe? Or maybe there's a step I'm missing to tell the JobDetail to flush the contents of its JobDataMap to the JobStore?
I think your problem is with using the postfix ++ operator - when you do:
context.getJobDetail().getJobDataMap().put("count", count++);
you're setting the value in the map to count and THEN incrementing count.
To me it looks like you wanted:
context.getJobDetail().getJobDataMap().put("count", ++count);
which would only need to be done once.
As you know, in Quartz, the trigger and the job are separate, rather than combined with some schedulers. They might be allowing you to add values to the datamap which are specific at the trigger level rather than the job level, etc.
I think it allows you to execute the same end job with a different set of data, but still have some common data at the job level.
As scpritch76 answered, the job and trigger are separate so that there can be many triggers (schedules) for a given job.
The job can have some base set of properties in the JobDataMap, and then the triggers can provide additional properties (or override base properties) for particular executions of the job in their JobDataMaps.
#PersistJobDataAfterExecution
#DisallowConcurrentExecution
public class DynamicTestJob implements Job
{
private static final Logger log = LoggerFactory.getLogger(DynamicTestJob.class);
#Override
public void execute(final JobExecutionContext context)
{
final JobDataMap jobDataMap = context.getJobDetail().getJobDataMap();
Integer counter = (Integer) jobDataMap.get("counter");
if (counter == null)
{
counter = 1;
}
else
{
counter++;
}
jobDataMap.put("counter", counter);
System.out.println(counter);
}
}
I have the following method that builds a new JobDetail instance;
private JobDetail getJob(JobID jobID) throws SchedulerException {
Class<? extends Job> jobClass = jobID.getJobClass();
if(jobClass != null){
return JobBuilder
.newJob(jobClass)
.withIdentity(jobID.jobName(), jobID.jobGroup())
.requestRecovery(true)
.build();
}
return null;
}
Note: JobID is just a helper class of mine that provides all the necessary raw data required to build a JobDetail
Then another method that does the actual scheduling;
doSchedule(Scheduler scheduler, JobDetail job, String triggerName){
Trigger trigger = buildSomeTrigger(triggerName);
//check whether job exists in scheduler instance
if(scheduler.checkExists(job.getKey())){
//If trigger also exists, then it probably holds new info
//So, reschedule the existing job with the trigger
if(scheduler.checkExists(trigger.getKey())){
System.out.println("update job with Trigger");
job = job.getJobBuilder().storeDurably(true).build();
scheduler.addJob(job, true);
Trigger oldTrigger = scheduler.getTrigger(trigger.getKey());
scheduler.rescheduleJob(oldTrigger.getKey(), trigger);
}else{
//If trigger does not exist, it's an entirely new trigger
//Add the new trigger to the existing job
System.out.println("save new trigger for job");
trigger = trigger.getTriggerBuilder().forJob(job).build();
scheduler.scheduleJob(trigger);
}
}else{
//If job does not exist, schedule new job with the trigger
System.out.println("schedule new job with trigger");
scheduler.scheduleJob(job, trigger);
}
}
EDIT: Here's what getNewSchedulerInstance() looks like;
private Scheduler getNewSchedulerInstance() {
Scheduler scheduler = null;
try {
scheduler = new StdSchedulerFactory("quartz.properties").getScheduler();
scheduler.setJobFactory(cdiJobFactory); //<== Utilizes the JobFactory implementation specified in the CdiJobFactory.java class
scheduler.getListenerManager().addJobListener(new SimpleJobListener());
scheduler.getListenerManager().addTriggerListener(new SimpleTriggerListener());
} catch (SchedulerException ex) {
System.out.println("Scheduler instantiation failed!");
ex.printStackTrace();
}
return scheduler;
}
Then finally in another method, I have the following;
//This returns a new instance of Scheduler
Scheduler scheduler = getNewSchedulerInstance();
if(scheduler != null){
JobID jobID = new ExtendedJobID(); // <== extends JobID
JobDetail job = getJob(jobID);
doSchedule(scheduler, job);
}
Normally I expect this to print;
schedule new job with trigger
But instead it's printing;
save new trigger for job
EDIT: And hence throws the following exception;
org.quartz.JobPersistenceException: Couldn't store trigger 'GOALS.ACTIVATE_GOALS_0:0' for 'GOALS.ACTIVATE_GOALS' job:
The job (GOALS.ACTIVATE_GOALS) referenced by the trigger does not exist.
[See nested exception: org.quartz.JobPersistenceException: The job (GOALS.ACTIVATE_GOALS) referenced by the trigger does not exist.]
This suggests that the scheduler.checkExists(job.getKey()) returns true
scheduler.checkExists(trigger.getKey()) returns false
Yet exception says that The job (*jobName*) referenced by the (*trigger*) does not exist
So, this issuse only gets me confused as it seems that scheduler.checkExists(...) is failing to appropriately check the existence of the job or not in the scheduler
The Exception shouldn't even get thrown if the check did what I expect it to do;
But as you can see, the JobDetail is newly built and has not in any way been previously associated with the scheduler...
So I'm wondering whether i'm missing some Quartz Scheduler points?...
If so, can someone please explain what I might be doing wrong here?...
Or could this actually be a bug?...
Are there any work-arounds?
I am running a scheduled task in the web application using the java SingleThreadScheduledExecutor
The problem I have is - How do I identify whether the scheduler is still running and has not crashed?
Is there a better way of doing it rather than having another scheduler to check this particular scheduler
there is actually a way to check
public class TaskSchedulerService{
private final ThreadPoolTaskScheduler taskScheduler; //initialize it here or in constructor
private Map<String,ScheduledFuture<?>> scheduleMap = new ConcurrentHashMap<>();
public TaskSchedulerServiceImpl() {
this.schedulerName = schedulerName;
taskScheduler.initialize();
}
public boolean isScheduled(String taskId) {
final ScheduledFuture<?> exits = scheduledTasks.get(taskId);
return exits != null && exits.isDone();
}
public ScheduledFuture<?> schedule(String taskId, Runnable task, Date date) {
ScheduledFuture<?> scheduled = scheduleMap.get(taskId);
if (scheduled==null ) {
ScheduledFuture<?> future = taskScheduler.schedule(task, date);
scheduleMap.put(taskId, future);
return future;
} else {
// log it is already scheduled
return scheduled;
}
}
i know it is too late but i hope others can get benefit from it
The logic behind the implementation is whenever you are trying to schedule a task, you will have to add it to the map with the taskId as well, in this case it is better to find any task if exists in MAP or if needed remove it as well as checking if that task is done or not
The answer depends on what your scheduler does really. For instance, you can produce a file or update a field in a db or such thing that can be checked and the time interval (from now to last update) can be calculated. In your case, if the time interval of file creation or db updated is more than half an hour this means the job did stop. But notice that scheduled jobs are meant to last forever like love.
I want to write a back-ground job (EJB 3.1), which executes every minute. For this I use the following annotation:
#Schedule(minute = "*/1", hour = "*")
which is working fine.
However, sometimes the job may take more than one minute. In this case, the timer is still fired, causing threading-issues.
Is it somehow possible, to terminate the scheduler if the current execution is not completed?
If only 1 timer may ever be active at the same time, there are a couple of solutions.
First of all the #Timer should probably be present on an #Singleton. In a Singleton methods are by default write-locked, so the container will automatically be locked-out when trying to invoke the timer method while there's still activity in it.
The following is basically enough:
#Singleton
public class TimerBean {
#Schedule(second= "*/5", minute = "*", hour = "*", persistent = false)
public void atSchedule() throws InterruptedException {
System.out.println("Called");
Thread.sleep(10000);
}
}
atSchedule is write-locked by default and there can only ever be one thread active in it, including calls initiated by the container.
Upon being locked-out, the container may retry the timer though, so to prevent this you'd use a read lock instead and delegate to a second bean (the second bean is needed because EJB 3.1 does not allow upgrading a read lock to a write lock).
The timer bean:
#Singleton
public class TimerBean {
#EJB
private WorkerBean workerBean;
#Lock(READ)
#Schedule(second = "*/5", minute = "*", hour = "*", persistent = false)
public void atSchedule() {
try {
workerBean.doTimerWork();
} catch (Exception e) {
System.out.println("Timer still busy");
}
}
}
The worker bean:
#Singleton
public class WorkerBean {
#AccessTimeout(0)
public void doTimerWork() throws InterruptedException {
System.out.println("Timer work started");
Thread.sleep(12000);
System.out.println("Timer work done");
}
}
This will likely still print a noisy exception in the log, so a more verbose but more silently solution is to use an explicit boolean:
The timer bean:
#Singleton
public class TimerBean {
#EJB
private WorkerBean workerBean;
#Lock(READ)
#Schedule(second = "*/5", minute = "*", hour = "*", persistent = false)
public void atSchedule() {
workerBean.doTimerWork();
}
}
The worker bean:
#Singleton
public class WorkerBean {
private AtomicBoolean busy = new AtomicBoolean(false);
#Lock(READ)
public void doTimerWork() throws InterruptedException {
if (!busy.compareAndSet(false, true)) {
return;
}
try {
System.out.println("Timer work started");
Thread.sleep(12000);
System.out.println("Timer work done");
} finally {
busy.set(false);
}
}
}
There are some more variations possible, e.g. you could delegate the busy check to an interceptor, or inject a singleton that only contains the boolean into the timer bean, and check that boolean there, etc.
I ran into the same problem but solved it slightly differently.
#Singleton
public class DoStuffTask {
#Resource
private TimerService timerSvc;
#Timeout
public void doStuff(Timer t) {
try {
doActualStuff(t);
} catch (Exception e) {
LOG.warn("Error running task", e);
}
scheduleStuff();
}
private void doActualStuff(Timer t) {
LOG.info("Doing Stuff " + t.getInfo());
}
#PostConstruct
public void initialise() {
scheduleStuff();
}
private void scheduleStuff() {
timerSvc.createSingleActionTimer(1000l, new TimerConfig());
}
public void stop() {
for(Timer timer : timerSvc.getTimers()) {
timer.cancel();
}
}
}
This works by setting up a task to execute in the future (in this case, in one second). At the end of the task, it schedules the task again.
EDIT: Updated to refactor the "stuff" into another method so that we can guard for exceptions so that the rescheduling of the timer always happens
Since Java EE 7 it is possible to use an "EE-aware" ManagedScheduledExecutorService, i.e. in WildFly:
In for example a #Singleton #Startup #LocalBean, inject the default "managed-scheduled-executor-service" configured in standalone.xml:
#Resource
private ManagedScheduledExecutorService scheduledExecutorService;
Schedule some task in #PostConstruct to be executed i.e. every second with fixed delay:
scheduledExecutorService.scheduleWithFixedDelay(this::someMethod, 1, 1, TimeUnit.SECONDS);
scheduleWithFixedDelay:
Creates and executes a periodic action that becomes enabled first
after the given initial delay, and subsequently with the given delay
between the termination of one execution and the commencement of the
next.[...]
Do not shutdown the scheduler in i.e. #PreDestroy:
Managed Scheduled Executor Service instances are managed by the
application server, thus Java EE applications are forbidden to invoke
any lifecycle related method.
well I had a similar problem. There was a job that was supposed to run every 30 minutes and sometimes the job was taking more than 30 minutes to complete in this case another instance of job was starting while previous one was not yet finished.
I solved it by having a static boolean variable which my job would set to true whenever it started run and then set it back to false whenever it finished. Since its a static variable all instances will see the same copy at all times. You could even synchronize the block when u set and unset the static variable.
class myjob{
private static boolean isRunning=false;
public executeJob(){
if (isRunning)
return;
isRunning=true;
//execute job
isRunning=false;
}
}
We have several Quartz jobs configured in our application. During development, we leave the quartz scheduler in standby - however, we sometimes want to start a job manually (for development purposes). If I call fireTrigger, it tells me I need to start the scheduler. However, if I start the scheduler, it will also immediately schedule all the other jobs, which is not what I want (since they may trigger while I'm debugging the manually fired job).
I could pause all triggers when I start the scheduler, but then I have to deal with misfire instructions etc.
Is there a simple way to fire off a job manually without having to deal with pausing and misfires (i.e. a fireTrigger which works even if the scheduler is in standby)?
this is the loop you will require to fire the job manually:
SchedulerFactory stdSchedulerFactory = new StdSchedulerFactory();
Scheduler scheduler = stdSchedulerFactory.getScheduler();
// loop jobs by group
for (String groupName : scheduler.getJobGroupNames()) {
// get jobkey
for (JobKey jobKey : scheduler.getJobKeys(GroupMatcher.jobGroupEquals(groupName))) {
String jobName = jobKey.getName();
String jobGroup = jobKey.getGroup();
scheduler.triggerJob(jobName, jobGroup);
}
}
All the Jobs registered in the Quartz Scheduler are uniquely identified by the JobKey which is composed of a name and group . You can fire the job which has a given JobKey immediately by calling triggerJob(JobKey jobKey) of your Scheduler instance.
// Create a new Job
JobKey jobKey = JobKey.jobKey("myNewJob", "myJobGroup");
JobDetail job = JobBuilder.newJob(MyJob.class).withIdentity(jobKey).storeDurably().build();
// Register this job to the scheduler
scheduler.addJob(job, true);
// Immediately fire the Job MyJob.class
scheduler.triggerJob(jobKey);
Note:
scheduler is the Scheduler instance used throughout your application . Its start() method should be already called after it is created.
The job is the durable job which cannot attach any triggers or cron to it .It can only be fired programmatically by calling `triggerJob(JobKey jobKey)`.
You can try to add a trigger filter in your scheduler
this.scheduler.addGlobalTriggerListener(new DebugExecutionFilter());
The debug execution filter will add a veto when the execution is not volatile (not scheduled to run immediately) and you are in debug mode .
Here is an implementation example :
private static class DebugExecutionFilter implements TriggerListener
{
public DebugExecutionFilter()
{
}
#Override
public String getName()
{
return "Task execution filter";
}
#Override
public void triggerFired(Trigger trigger, JobExecutionContext context)
{
// Do nothing
}
/* (non-Javadoc)
*
* #see org.quartz.TriggerListener#vetoJobExecution(org.quartz.Trigger, org.quartz.JobExecutionContext) */
#Override
#SuppressWarnings("unchecked")
/**
* A veto is added if :
* - For non volatile trigger if we are in debug mode
*/
public boolean vetoJobExecution(Trigger trigger, JobExecutionContext context)
{
try
{
//
if ( !trigger.isVolatile() && isDebugMode() )
{
return true;
}
//task is run by scheduler.triggerJobWithVolatileTrigger() for immediate schedule
//or task is schedule and we are not in debugMode
return false;
}
#Override
public void triggerMisfired(Trigger trigger)
{
// do nothing
}
#Override
public void triggerComplete(Trigger trigger, JobExecutionContext context, int triggerInstructionCode)
{
// do nothing
}
}
No need for start-time and end-time.
<trigger>
<cron>
<name>TestTrigger</name>
<group>CronSampleTrigger</group>
<description>CronSampleTrigger</description>
<job-name>TestJob</job-name>
<job-group>jobGroup1</job-group>
<!--<start-time>1982-06-28T18:15:00.0Z</start-time>
<end-time>2020-05-04T18:13:51.0Z</end-time>-->
<cron-expression>0 0/1 * * * ?</cron-expression>
</cron>
</trigger>