Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

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

I'm sorry, I really don't understand what you're trying trying to accomplish.

If you have 300 tasks, you shouldn't need 300 schedulers. You should just need one scheduler with 300 defined jobs within it.

Perhaps you could make another attempt at explaining what you are trying to accomplish.

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

I'm still confused.

If you are considering using Quartz, why wouldn't you just do the following:

* Create job that knows how to do the page crawling work (or invokes your code that already knows how to do that)
* Store instances of that job in the scheduler, one for each user. (use the jobdatamap to store details such as urls, or whatever to pass to the code doing the work).
* When the user sets a schedule for their job to run at, define a trigger with the appropriate schedule, point it at the user's specific job, and use scheduler.scheduleJob() or scheduler.rescheduleJob() to set it up
* Quartz will now execute the job whenever the time is appropriate. You have no need to ask quartz if the job should be ran, it will be triggered by quartz whenever the schedule (trigger(s)) says it should be.

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?

I have found the Scheduler available from quartz to be extremely thorough. I have yet to need info about a job that the scheduler does not have access to. For example, If you want to print the name, Run time and next fire time of your currently executing jobs, you can do the following:
Code:

  List<JobExecutionContext> jobs = sched.getCurrentlyExecutingJobs();
 		     
 		     for (JobExecutionContext jec: jobs)
 		     {
 		    	 LOGGER.debug("Job Name:"+jec.getJobDetail().getName());
 		    	 LOGGER.debug("Job Run Time:"+jec.getJobRunTime());
 		    	 LOGGER.debug("Next Fire Time:"+jec.getNextFireTime()); 
 
 		     }

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

well at least rate my response.