Can someone let me know the difference between deleteJob() and unscheduleJob() of quartz 1.8.5?
Thanks.
If you look at the implementations of both methods in QuartzScheduler.java , you'll notice that deleteJob(JobKey jobKey)
loops through all the triggers having a reference to this job, to unschedule them
removes the job from the jobstore
whereas unscheduleJob(TriggerKey triggerKey) just unschedules a trigger, so if other triggers reference this job, they won't be changed.
Related
Recently, I am studying the problem of task scheduling in Flink. My purpose is to schedule subtasks to a slot of the specified node according to my own needs by modifying some source codes of the scheduling part. Through remote debugging and checking the source code, I found the following method call stack, most of which I can't understand (the comments are a little less), especially in this method: org.apache.flink.runtime.jobmaster.slotpool.SchedulerImpl#allocateMultiTaskSlot. I guess the code that allocates slots to tasks is around here. Because it is too difficult to read the source code, I have to ask you for help. Of course, if there is a better way to achieve my needs, please specify one or two. Sincerely look forward to your reply! Thank you very much!!!
The method call stack is as follows(The version of Flink I use is 1.11.1):
org.apache.flink.runtime.jobmaster.JobMaster#startJobExecution
org.apache.flink.runtime.jobmaster.JobMaster#resetAndStartScheduler
org.apache.flink.runtime.jobmaster.JobMaster#startScheduling
org.apache.flink.runtime.scheduler.SchedulerBase#startScheduling
org.apache.flink.runtime.scheduler.DefaultScheduler#startSchedulingInternal
org.apache.flink.runtime.scheduler.strategy.EagerSchedulingStrategy#startScheduling
(This is like the method call chain of PipelinedRegionSchedulingStrategy class. In order to simply write it as the method call chain of EagerSchedulingStrategy class, it should have no effect)
org.apache.flink.runtime.scheduler.strategy.EagerSchedulingStrategy#allocateSlotsAndDeploy
org.apache.flink.runtime.scheduler.DefaultScheduler#allocateSlotsAndDeploy
org.apache.flink.runtime.scheduler.DefaultScheduler#allocateSlots
org.apache.flink.runtime.scheduler.DefaultExecutionSlotAllocator#allocateSlotsFor
org.apache.flink.runtime.executiongraph.SlotProviderStrategy.NormalSlotProviderStrategy#allocateSlot
org.apache.flink.runtime.jobmaster.slotpool.SchedulerImpl#allocateSlot
org.apache.flink.runtime.jobmaster.slotpool.SchedulerImpl#allocateSlotInternal
org.apache.flink.runtime.jobmaster.slotpool.SchedulerImpl#internalAllocateSlot
org.apache.flink.runtime.jobmaster.slotpool.SchedulerImpl#allocateSharedSlot
org.apache.flink.runtime.jobmaster.slotpool.SchedulerImpl#allocateMultiTaskSlot
(I feel that this is the key to allocate slot for subtask, that is, execution vertex, but there is no comment, and I don't understand the process idea, so I can't understand it.)
I don't understand the GTask functionality? why do I need this?
In my mind it is like callback.. you set a callback to a source in some context and this callback is then called when event is happening.
In general, i'm a bit confused about what is a Context and a Task in GLib and why do we need them.
In my understanding there is a main loop (only 1?) that can run several contexts (what is a context?) and each context is related to several sources which in their turn have callbacks that are like handlers.
So can someone please make some sense for me in it all.
I don't understand the GTask functionality? why do I need this? In my mind it is like callback.. you set a callback to a source in some context and this callback is then called when event is happening.
The main functionality GTask exposes is easily and safely running a task in a thread and returning the result back to the main thread.
In general, i'm a bit confused about what is a Context and a Task in GLib and why do we need them. In my understanding there is a main loop (only 1?) that can run several contexts (what is a context?) and each context is related to several sources which in their turn have callbacks that are like handlers.
For simplicity I think its safe to consider contexts and loops the same thing and there can be multiple of them. So in order to be thread-safe the task must know which context the result is returned to.
We're using Quartz 1.8.6 in our app. We are using CronTriggers for hourly and nightly jobs. We would like to set things up such that if there is a misfire, we want to skip the job until the next cron time rolls around.
For simple jobs, it appears you can do a
nightlyTrigger.setMisfireInstruction(SimpleTrigger.MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT);
However, it appears that this does not work with CronTrigger. What is the Misfire instruction to use in this case?
You want to use CronTrigger.MISFIRE_INSTRUCTION_DO_NOTHING.
SimpleTrigger.MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT is telling Quartz that, upon one or more misfires, it must:
reschedule the trigger to fire upon the next scheduled date (not firing, i.e. ignoring, missed executions).
Also, set the "repetitions left" counter as if all missed executions had run correctly (not accounting for missed runs either).
So basically this misfire instruction tells Quartz to do nothing at all, smile and keep going like nothing ever happened. The KEEP CALM of misfire instructions.
The equivalent instruction for Cron triggers is much more aptly named: CronTrigger.MISFIRE_INSTRUCTION_DO_NOTHING.
I am using Jboss-seam 2.2.2.Final and I have some quartz jobs. During the application execution, I have to verify if a specific job is running.
I already have access to the jobs, but each one has a name that is created by quartz. Here is the code for the seam injection:
#In("org.jboss.seam.async.dispatcher")
private QuartzDispatcher quartzDispatcher;
To get the running jobs, I have this code:
Scheduler scheduler = quartzDispatcher.getScheduler();
List<JobExecutionContext> currentJobs;
currentJobs = scheduler.getCurrentlyExecutingJobs();
for (JobExecutionContext jobCtx: currentJobs){
System.out.println(jobCtx.getJobDetail().getName());
}
Anyone know's how to put a name on a quartz job, using jboss-seam? I have doing some research and found this ticket on jira: https://issues.jboss.org/browse/JBSEAM-4399
Seam generates an UUID-based unique name for each job, there's no direct way of overriding this. Your alternatives are:
Use the patch found, this requires building a custom Seam library with the customized code added.
Override the OOTB quartz dispatcher with your own custom dispatcher, override the scheduleWithQuartzService method and use your own scheme for naming the job (look at the source code for org.jboss.seam.async.QuartzDispatcher you'll see that it calls a nextUniqueName() method that generates a new unique name for the job, you need to get the job name from elsewhere, eventually in the same way it is done in the patch you found, via an annotation).
Instead of trying to see if the job is running based on its name, you can create a quartz event listener implementing org.quartz.JobListener and register when a job begins and ends execution in a global hashtable or something like that. Then you lookup the job in the hashtable to get its status rather than searching it by name. This however works only if your scheduler is not clustered (quartz will notify only the listener in the local node, other nodes will not know the job was triggered).
I am using quartz to schedule my job. Sometimes I need listener to do something after a run, but sometimes I don't need it to run.
Can I pass parameter from job instance to joblistener?
See JobExecutionContext.setResult() and getResult(), which you can use from within the job and the listener.