I try to run emergency job immediately after scheduled with quartz.
my code is below.I give current time as startTime.
Bıt it takes 30- 40 seconds to run job after schedule.How can run immediately.
// Trigger the job to run now, and then repeat every 40 seconds
jobTrigger= newTrigger()
.withIdentity(Long.toString(emergencyJob.getId()), Long.toString(emergencyJob.getVariant().getId()))
.withPriority(emergencyJob.getPriority())
.startAt(new Date(ctime))
.withSchedule(simpleSchedule().withMisfireHandlingInstructionFireNow()
)
.build();
scheduler.scheduleJob(jobDetail, jobTrigger);
You can also fire it with:
scheduler.triggerJob(jobDetail.getKey());
This is just a guess (it's been a while since I've used quartz), but since you create the Date instance before you actually call build(), it may not be able to meet that time constraint and simply fires 40 seconds later when the next scheduled trigger fires. Try something like this to confirm:
.startAt(new Date(System.currentTimeMillis() + 1000))
Play with the 1000ms value to suit your needs. This is to give it a bit more time to meet the first scheduled trigger.
Probably bit late, but maybe someone will find this useful. I had same issue with quartz on JBoss AS (triggers executed late - approximately 20-30 seconds, for no obvious reason). I came to conclusion that this is caused by some bug in JBoss. Same application worked fine on glassfish. I have changed only PU in order to work with eclipse link and other persistence worked fine on JBoss, so I don't suppose issue there. This behaviour occured only when using quartz database task store, with RAM store it worked fine.
To answear the question. If you use database taskstore, consider changing it to RAM store for me that caused triggers to be fired at time.
Related
I'm using java quartz(2.3.1) and I have a setup where I'm using postgres as the job store and I have 3-4 machines all running the scheduler (vertical scaling). I want the rds to act as a source of truth and if I have a job with the schedule of repeat every 1 hour, I want it to run on any one of the machines. I don't care which one it runs on as long as it is one machine triggered in that hour.
I noticed that this works really well most of the time but I have recently had a trigger which runs once ever hour and about once every two days I see two of my machines getting triggered. I have noticed that my isClustered property is false which I have now set to true, but I'm not sure how this would help since if this was the problem, this issue would be happening a 100% of the time rather than rarely. Could anyone tell me what I should be looking into to actually fix this issue?
org.quartz.jobStore.isClustered = true
ensures proper database row locks are applied to the trigger before picking it, if that property was false both instances can pick up one trigger(race condition) before one could change status of that trigger.
http://www.quartz-scheduler.org/documentation/quartz-1.8.6/configuration/ConfigJDBCJobStoreClustering.html
I'm programming an update interface in my Android Things project. I can do manual update, with an user input. But I'm trying to schedule an auto-update every night at midnight. I want to use a custom UpdatePolicy with a deadline but I failed to use it.
I tried this in the onCreate method in my activity :
mUpdateManager.setPolicy(
new UpdatePolicy.Builder()
.setPolicy(POLICY_APPLY_AND_REBOOT)
.setUpdateDeadline(10, TimeUnit.SECONDS)
.build());
But there isn't any update after 10 seconds.
Maybe, I don't understand the deadline.
Do I use it wrong ?
The deadline has nothing to do with when an update check is performed. The usual schedule of update checks is
once shortly after boot
once every 5 hours (approximately) thereafter
(These times are not exact for reasons that aren't relevant to this discussion.)
The deadline reflects how long the device will let an available update sit without being applied before the device will force it to apply and reboot. The device doesn't know about an available update until it performs a check, so you could be waiting up to 5 hours for that.
The deadline is meant to operate on a longer timescale (for instance, 5 days, a week, etc). This is useful as a fallback in case there's some kind of bug with the update scheduler, or in case you allow users to postpone the update but don't want them to be able to do that forever.
To achieve what you want, you should schedule (using WorkManager, JobScheduler, etc) a task that runs at midnight each day and calls UpdateManager.performUpdateNow(UpdatePolicy.POLICY_APPLY_AND_REBOOT)
TL,DR: Update checks are very much a background thing. If you care about timing at all, use UpdateManager.performUpdateNow, but no more than once every 5 hours.
I have a non-concurrent quartz job running on 6 application server instances. A high level responsibility of the job is to walk through a DB table and process and update which ever row is expired. Now I see a behavior of the job which is not understandable.
I have a configuration by which the job should be triggered after 15 minutes, but as the span of a single run can be multiple days, each of this trigger after 15 minutes should be suppressed by a lock already acquired by running job instance.
So, the ideal behavior is, job starts running on one of the 6 server instances, it completes a single DB table iteration in let us say 3 days. Meanwhile, quartz is trying to push in another job every minutes, but as lock is already acquired, it should not. After 3 days when the first job run finishes quartz scheduler should succeed in starting another job, within <= 15 minutes of the first run endtime.
But, in reality I see a behavior, where the the job has run for some days and has not run for some of the days. some time this gap is as long as 8-10 days. I am unable to explain this scenario.
The closest theory I can think of, is that it might be the case that during a particular job run, the server instance got killed(due to deployment/redeployment), because of which the quartz did not get a chance to remove shared lock. So, all the attempts of acquiring a lock for next job run keep on failing till the orphan lock is not expired by an expiry date. The moment it got expired, a new job kicks in.
My question here is, what could be the possible explanations to this, and more importantly, how to debug it? Any leads to Quartz Lock management documentation for non-concurrent jobs can helpful.
I use DisallowConcurrentExecution annotation for non-concurrency.
I have an interesting issue with our web application. We recently had a huge concurrency problem with Quartz firing off the same java class in hundreds of threads at once causing contention on the database and completely locking our application. Before we were able to address the underlying issue, I had to set all misfire_instr to "1" (Do not re-fire a misfire) on the database table qrtz_triggers to get the application to come up and serve normal traffic. We then manually fired off the missed schedules slowly to avoid the concurrency issue.
I have fixed the concurrency issue and am ready to hot-deploy our application, but am afraid if I set the misfire_instr back to 2 (re-fire misfires), the missed schedules will re-fire again based on prev_fire_time?
Proposed solution - set prev_fire_time to a couple minutes before the next_fire_time so it thinks the last schedules went off. Is my assumption here correct that a schedule is considered missed if the prev_fire_time is before the last time represented by the cron expression?
I also see that schedules which have yet to run have -1 in the column, is this the default for a new schedule, perhaps I should be using this value instead?
Since we needed this to go in immediately, I decided to just try my luck with using -1 as the prev_fire_time value (and updating the triggers back to 2). This worked as expected.
I have a Job which runs everyday in 15 minutes but now the requirement is that we have to stop this job from 00h35 and 06h15 time .
We are using Quartz scheduler. How can I do this?
I don't use the quartz scheduler but I found the documentation here and had a quick look through it. There is an example 'Build a trigger that will fire now, then repeat every five minutes, until the hour 22:00' on page 23 which sounds similar to what you want to do (starting at 06h15 and finishing at 00h35)
If it's not what you're looking for, how about putting a bit of detail in your question, specifically what you've already tried.