I know I can specify .WithMisfireHandlingInstructionDoNothing() when building the trigger but some of my jobs are triggered via the IScheduler.TriggerJob() method, so without any triggers.
I can detect and log misfires in the ITriggerListener listener but how can I stop Quartz from trying to fire the job again? If I understand correctly .VetoJobExecution is not usable since the job has to be triggered successfully anyway.
Any other ideas?
Edit: my implementation
JobDataMap jobData = new JobDataMap(data);
IJobDetail jobTemplate = await jobScheduler.GetJobDetail(jobKey);
var jobTrigger = TriggerBuilder.Create()
.ForJob(jobTemplate)
.UsingJobData(jobData)
.WithSimpleSchedule(s => s.WithRepeatCount(0).WithMisfireHandlingInstructionNextWithRemainingCount())
.StartNow()
.Build();
await jobScheduler.ScheduleJob(jobTrigger);
Well if you just want the TriggerJob behavior you can achieve that just by adding one simple trigger to scheduler that is going to trigger immediately and configure retry policy for that. So if you can change the call sites of TriggerJob to create a simple trigger instead (maybe an extension method that allows to define the policy), the Quartz source for TriggerJob is here.
I think I've got it.
You have to use the WithMisfireHandlingInstructionNextWithRemainingCount policy, and WithRepeatCount(0).
But the trick here is to set the right value in the IScheduler MisfireThreshold to the misfire to be considered as a real misfire. I mean, if your misfire threshold is set to 60 seconds (default) then any job not executed in less than 60 seconds from schedule, will NOT be considered as a misfire. And so, the misfire policy will not be used.
In my case, with 3 second duration jobs, I had to set the WithMisfireThreshold to 1 second or less.
This way, the job is not retried if "really misfired".
Related
In Jenkins, I want to be able to delay the execution of a job, i.e. for 1 hour, after I click Build.
I want to set up the parameters, click Build and the job to stay in the Queue for 1 hour, without using an executor, and then start. I do not want to schedule a job periodically or sth like that. Just to force it to stay in the queue for a certain (maybe configurable) period of time.
Is there a way to do this?
Using sleep here is exactly the right thing to do. To workaround the fact that no new nodes are consumed and idle, just execute the sleep command on a special sleepnode. So every Job will use this sleepnode for sleeping, which means no additional nodes would get consumed.
node('sleeper') {
stage('Countdown 1hr') {
sleep 3600
}
}
node('buildnode1') {
stage('build') {
echo "What ever should be done here"
}
}
We have installed quartz.net scheduler service and configured a (memory)job to run daily # 10 pm. In case the server hosting this service is restarted, is there a way to force the job to run as soon as the service comes up? In normal scenario job should fire at 10pm as scheduled, but whenever the server/service is restarted, we want the job to run immediately even if it is not scheduled to run at that time. If there's some configuration value to achieve this, that would be the best option.
Write a little code that reads a small xml file (custom one of your own doing)....
and put it in your startup code.
foreach( xmlElement in yourXmlFile)
{
string someJobName= ""; /* read xml for jobName */
String someJobGroup= ""; /* read xml for job group name */
Trigger trigger = TriggerBuilder.newTrigger()
.withIdentity(someJobName, someJobGroup)
.startNow()
.build();
}
You can perform this with the help of WithMisfireHandlingInstructionFireAndProceed method of CronScheduleBuilder as shown below:
ITrigger trigger = TriggerBuilder.Create()
.WithIdentity("trigger1", "group1")
.StartNow()
.WithSchedule(CronScheduleBuilder
.WeeklyOnDayAndHourAndMinute(DayOfWeek.Monday, 09, 00)
.WithMisfireHandlingInstructionFireAndProceed()
//MISFIRE_INSTRUCTION_FIRE_NOW
.InTimeZone(TimeZoneInfo.FindSystemTimeZoneById("GTB Standard Time"))
)
//.ForJob(myJobKey)
.Build();
scheduler.ScheduleJob(job, trigger);
I have scheduled a job
Worker.perform_at(time, args)
And I can fetch the scheduled jobs
job = Sidekiq::ScheduledSet.new.find_job(jid)
job.args # this is the args I passed above
I need to update the args that will be passed to the worker when it is called, i.e. update job.args. How do I do that?
This won't work:
job.args = new_args
Sidekiq::ScheduledSet.new.to_a[0] = job
Well update the task is not the way achieving it cancel job and create new with new args:
job = Sidekiq::ScheduledSet.new.find_job(jid)
## time = job.time // Or just set time needed.
Sidekiq::Status.cancel jid
Worker.perform_at(time, new_args)
it will also make it easier for you to debug and log the jobs because when you edit/update them on the fly could cause bugs that very hard to identify.
I'm building a windows service which is performing a scheduled task which processes a queue of commands (from a legacy system) at a regular interval (once per min) using Quartz.net
If the task takes longer than 1 min, which would be unusual but possible under certain circumstances, I'd like it to simple ignore the triggers it missed firing.
However I can't seem to get this to happen. It does the processing and then quickly fires all the triggers it missed in quick succession. As I understand you can set a threshold for the misfires but I don't seem to be-able to get this working.
I'm using [DisallowConcurrentExecution()] on the Job to ensure only one instance of the job is running at any one time.
Below are a couple of snippets. First passing in some config info - is this how you set the misfire threshold?
NameValueCollection config = new NameValueCollection();
config.Add("quartz.jobStore.misfireThreshold", "600000");
schedFact = new StdSchedulerFactory(config);
Building a trigger with what I assume to be the correct setting of Ignore misfires:
var trigger = TriggerBuilder.Create()
.WithIdentity("trigger1", "group1")
.StartNow()
.WithSimpleSchedule( x => x.WithMisfireHandlingInstructionIgnoreMisfires()
.WithIntervalInSeconds(60)
.RepeatForever())
.Build();
Thoughts much appreciated.
Code for the Job:
Just playing with rough ideas at this point so just running in a console app and randomly delaying a job so it shoots over the interval which is just set at 10 seconds for this. All the backed up misfires fire in quick succession after a couple of delays.
[DisallowConcurrentExecution()]
public class SomeJob : IJob
{
public SomeJob() { }
public void Execute(IJobExecutionContext context)
{
Random rnd = new Random(DateTime.UtcNow.Second);
int delay = rnd.Next(2);
Console.WriteLine("Executing Job with delay of "+ delay + " at " + DateTime.UtcNow.ToString());
if (delay == 1)
{
System.Threading.Thread.Sleep(1000 * 25); // sleep for 25 seconds
}
}
}
Example console output:
Executing Job with delay of 1 at 21/05/2015 21:27:17
Executing Job with delay of 1 at 21/05/2015 21:27:42
Executing Job with delay of 0 at 21/05/2015 21:28:07 <-- stacked misfires
Executing Job with delay of 0 at 21/05/2015 21:28:07 <--
Executing Job with delay of 0 at 21/05/2015 21:28:07 <--
Executing Job with delay of 0 at 21/05/2015 21:28:07 <--
Executing Job with delay of 0 at 21/05/2015 21:28:16
Executing Job with delay of 0 at 21/05/2015 21:28:26
Executing Job with delay of 1 at 21/05/2015 21:28:36
Executing Job with delay of 0 at 21/05/2015 21:29:01
Executing Job with delay of 0 at 21/05/2015 21:29:01
Executing Job with delay of 1 at 21/05/2015 21:29:06
WithMisfireHandlingInstructionIgnoreMisfires() is the wrong method for what you want, it doesn't mean the job will not trigger misfires, it means it will fire all triggers that were missed as soon as possible and will then go back to ordinary schedule. Which is what you see happening.
What you need is WithMisfireHandlingInstructionNextWithRemainingCount(). This will signal the scheduler to ignore misfires and wait for the next scheduled time.
Misfiring strategies can be a bit confusing, for a concise explanation look here (it's for the java scheduler but it doesn't matter).
Even with the right strategy, you need to understand how the misfire threshold works- if you get it wrong your misfired trigger may still fire.
From the documentation: "A misfire is the time span by which a trigger must have missed its next-fire-time, in order for it to be considered "misfired" and thus have its misfire instruction applied".
You've set the value to 600000 milliseconds (and this value is for all triggers, unfortunately there is no threshold per trigger)- the misfire strategy will only be applied if your trigger fires 600000 milliseconds after the time it should have been fired. You can lower or increase it according to your requirement.
For more about the misfire threshold, read here.
I am using Quartz2 Plugin, and am trying to dynamically trigger a very simple job. When the user performs a certain action, the job should be triggered some certain number of minutes in the future, and only run once.
I have tried using the simple 'schedule' method that takes a date and job data:
def sendTime = new Date()
use(groovy.time.TimeCategory) {
sendTime = sendTime + (connectionInstance.timeout).minutes
println "I will send the job at $sendTime"
}
ReportSmssyncTimeoutJob.schedule(sendTime, [connectionId:params.id])
In this setup, I find that the job actually triggers immediately instead of waiting until 'sendTime'.
My second attempt, after looking at the plugin source, was to use a SimpleTrigger
def sendTime = new Date()
use(groovy.time.TimeCategory) {
sendTime = sendTime + (connectionInstance.timeout).minutes
println "I will send the job at $sendTime"
}
// arguments here are: jobKey='test', startTime=sendTime, repeatCount=0, repeatInterval=1 (zero not allowed), job-arguments)
def trigger = TriggerHelper.simpleTrigger(new JobKey("test"), sendTime, 0, 1, [connectionId:params.id])
ReportSmssyncTimeoutJob.schedule(trigger)
In this setup, the job also triggers immediately. Is there something wrong with the SimpleTrigger implementation which prevents it from waiting until startDate?
Unfortunately, switching to the main 'quartz' plugin (which now has support for Quartz 2) is not an option as I am working on a project that has loads of jobs set up to work with the quartz2 plugin.
I asked this on the Grails mailing list and got the answer: this is a bug in the quartz2 plugin. It should be fixed in the next release (bug was noted in 0.2.3).
Update: tested this in v2.1.6.2 of the quartz2 plugin, and can confirm that both of the approaches in my question now work.