I have a quartz job schedule like so:
_scheduler.ScheduleJob(job,
TriggerBuilder.Create().ForJob(job)
.WithSimpleSchedule(x =>
x.WithIntervalInSeconds(requeryTime.ToInt32())
.RepeatForever()
.WithMisfireHandlingInstructionNowWithRemainingCount()
)
.StartNow()
.Build())
To test I have the schedule run every 10 seconds. If I pause the service and then resume, I can still see all the jobs being called one after another. I want Quartz to ignore (do not queue) the jobs and just resume the schedule.
e.g. If the job runs every 10 secs and I pause the service for 1 minute, I get 6 jobs run in quick succession.
How do I go about ensuring Quartz ignores those jobs?
Short answer is to change the misfireThreshold in the configuration:
<add key="quartz.jobStore.misfireThreshold" value="60000" />
The default is 60000 milliseconds (60 seconds).
org.quartz.jobStore.misfireThreshold
The the number of milliseconds the scheduler will 'tolerate' a trigger
to pass its next-fire-time by, before being considered "misfired". The
default value (if you don't make an entry of this property in your
configuration) is 60000 (60 seconds).
Since your trigger runs every 10 seconds you can reduce the threshold to 9 seconds and it should work as you expect.
If you want to learn more about the strategies involved you can read this article and this one as well.
A similar question has been asked recenlty and Circular Reference gave a really good answer.
Related
I have a rails api app where receives a bunch of requests and then, for each, it executes a job, but I want to prevent it job being called immediately, I need it delay 2 seconds. So for that I have MyAwesomeJob.perform_in(2.seconds, stuff). So looking to sidekiq it goes right after 2 seconds. But next request goes right away.
What I need is: having 10 requests in 1 second it should enqueue 10 jobs and execute it one after other. (first gonna be in 2 seconds, next should wait last finish and go, so 4 seconds, 6seconds etc....)
Thanks!
We got one or two CheckPoint Failure during processing data every day. The data volume is low, like under 10k, and our interval setting is '2 minutes'. (The reason for processing very slow is we need to sink the data to another API endpoint which take some time to process at the end of flink job, so the time is Streaming data + Sink to external API endpoint).
The root issue is:
Checkpoints time out after 10 mins, this caused by the data processing time longer than 10 mins, so the checkpoint time out. We might increase the parallelism to fast the processing, but if the data become bigger, we have to increase the parallelism again, so don't want to use this way.
Suggested solution:
I saw someone suggest to set the pause between old and new checkpoint, but I have some question here is, if I set the pause time there, will the new checkpoint missing the state in the pause time?
Aim:
How to avoid this issue and record the correct state that doesn't miss any data?
Failed checkpoint:
Completed checkpoint:
subtask didn't respond
Thanks
There are several related configuration variables you can set -- such as the checkpoint interval, the pause between checkpoints, and the number of concurrent checkpoints. No combination of these settings will result in data being skipped for checkpointing.
Setting an interval between checkpoints means that Flink won't initiate a new checkpoint until some time has passed since the completion (or failure) of the previous checkpoint -- but this has no effect on the timeout.
Sounds like you should extend the timeout, which you can do like this:
env.getCheckpointConfig().setCheckpointTimeout(n);
where n is measured in milliseconds. See the section of the Flink docs on enabling and configuring checkpointing for more details.
Jenkins job trigger cron expression format is ? ? ? ? ?.
It cannot possible set the seconds unit.
But I want schedule seconds unit, like run at everyday 15:20:10.
Because there is a job with cron(0 12 * * *) and every minute job, and these two job must not to run simultaneously.
How can I do that?
Thanks for help.
you can have several options to do that :
use lock plugin to wait until your first job run will finish and only than trigger it.
use the Quiet period option in the Job configuration , add 10 seconds so the job will sleep 10 seconds after it trigger.
I have a NSTimer (running on main thread) that is supposed to go off every 0.02s. However, I notice that as memory usage start going up (the app captures a frame every tick and stores in an array) subsequent ticks begin to take more then 0.02s.
How can I solve this issue? I'm starting to think NSTimer is not suited for high-frequency tasks like this.
As the docs state,
A timer is not a real-time mechanism; it fires only when one of the
run loop modes to which the timer has been added is running and able
to check if the timer’s firing time has passed. Because of the various
input sources a typical run loop manages, the effective resolution of
the time interval for a timer is limited to on the order of 50-100
milliseconds.
Since 100 milliseconds = .1 seconds and your timer is supposed to run every 0.02 seconds, your timer schedule is far shorter than the timer's effective resolution and so you timer can easily get out of sync.
I'm trying out Quartz.net, which would possibly solve an issue of mine. However I can not seem to find a way to start a job at a given time of day (07:30) to run a number of times (1000) with a interval in milliseconds (1).
I've tried a CronSchedule, but intervals can not be set. With SimpleSchedule, a start time can not be set and with DailyTimeIntervalSchedule I can not set interval in milliseconds. I've also tried to combine a setup with the varoius with the fluent api, to no avale.
Is what I try to achieve actually not possible in Quartz.net?
This might be what you are after:
IJobDetail theJobToRun = JobBuilder.Create<NoOpJob>().Build();
var trigger = TriggerBuilder.Create()
.StartAt(DateBuilder.DateOf(7, 30, 0))
.WithSimpleSchedule(x => x
.WithInterval(TimeSpan.FromMilliseconds(1))
.WithRepeatCount(999))
.ForJob(theJobToRun)
.Build();
Just as sgmoore noted, you might not get millisecond precision as your thread pool will be saturated with jobs and it all depends how much work they true. Quartz.NET infrastructure will also take its own time watching for fire times and instantiating jobs.