Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

That makes perfect sense.

I'm pulling these out of a database where a user can select a start date, end date, and recurrence schedule.

TriggerUtils.computeFireTimesBetween() should work for me.

Thank you!

I'm setting up triggers to fire in the future, but they always fire immediately when the scheduler starts (or if the scheduler is started, right when they are added).

I believe there is something I'm doing wrong, but I'm not sure what it is.

When I create the trigger (I'm using both SimpleTrigger and CronTrigger), it always says 'null' for nextFireTime. Here is an example:

CronTrigger with cronExpression: "0 40 3 1 * ?"
start date: 2009-08-27 03:40:00
end date: 2040-01-01 01:00:00

Here is the toString() output:

Trigger 'DEFAULT.135_0': triggerClass: 'org.quartz.CronTrigger isVolatile: false calendar: 'null' misfireInstruction: 0 nextFireTime: null

Then when it has fired, it updates it with the correct nextFireTime:

Trigger 'DEFAULT. 135_0': triggerClass: 'org.quartz.CronTrigger isVolatile: false calendar: 'null' misfireInstruction: 0 nextFireTime: Tue Jun 01 03:40:00 CDT 2010

How do I get it to calculate that nextFireTime immediately, instead of just firing right away?

Thanks!

That's exactly what I need. Thanks so much, guys.

This makes sense, I think I'm just going to need to do some rearranging and rethink my current paradigm.

I do still have a "nice to have" requirement of being able to know when the job will run next. Is that possible?

A "job" in this case, is essentially a web crawling event.

You can define when you want your page crawled on a scheduled basis ("Every Monday", "5th day of the month", etc).

Those schedules, and the pages that should be crawled, can be updated at any time by a user, and those results are stored in a database, and is then checked every minute by my program, which asks the scheduler "should this job be run now based on the start time, schedule type, and current time?"

As a diagram it looks like this (completely asynchronous):

SCHEDULER -----> DATABASE <-------- USER UPDATES

So really, the problem comes from keeping the schedules updated but without making more than 10 concurrent calls to the database.

My original question still stands, independent of any specifications, "Can I ask Quartz, 'should this job be run now?'"

If so, this will be an easy replacement. If not, maybe I'm unaware of a better way to do this.

Thanks

Hello,

I have a unique requirement where I don't need to run a job when it is time, but rather, I need to know if a job SHOULD be run given the start date and the schedule type.

The details (if you need them):

I have written a scheduler that is currently not using Quartz. It runs on a delayed while loop. Every minute, it polls a database and gets a list of tasks. I have written a scheduling piece that tells me if a job should be run based off of the start time, current time, and schedule specification.

Ideally I would like to replace the piece that tells me if a job should be run, since it is really not very accurate (given my limited knowledge of
how schedulers work). The problems I see with using Quartz in a typical fashion is, I currently have ~300 tasks and that number is growing. So, as I
understand it, I would need 300 instances of Quartz. In addition to resource concerns, the architecture is what worries me most. Everything is based
off of the database, so users can make changes to their scheduled tasks on the fly, and those changes will be picked up on the next iteration of the
big while loop. It seems like the right way to handle this would be to have each Quartz task check the database, but I'm limited to 10 connections on
my database, so I can't have 300+ objects polling the database all the time.

Perhaps my understanding is backward, but if it's possible, I would like to be able to just ask a Quartz object the question, "Should this job be run
at this time?" with a minute of leeway (minutes are as granular as we get).

If anyone has any ideas, I'd love to hear it. Maybe I'm way off base, but right now, any information would be helpful.

Thanks!
Brian