Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

How about scheduler.pauseJob() ?

Or mark the job durable (so it can exist without triggers), and then unschedule all of the job's triggers.

1.7.3 is available now.

Regarding the load balancing, Quartz basically has a "first come first serve" algorithm - so there is no true balancing of load.

On a cluster with only one repeating trigger, this does tend to produce one node that does most of the work - because the nodes look for something to do on a periodic basis, AND immediately after they finish handling a trigger. Hence the node that just triggered the job is most likely to be the one that notices the new next fire time for the job.

However if there are multiple triggers in the scheduler, the effect is a generally random distribution of load across the cluster.

The Quartz 2.0 road map contains feature plans for being able to have more control over which nodes run which jobs.

sejer wrote:

- does Quartz come with a Web GUI ? It is hinted it does on this site: http://onjava.com/onjava/2005/09/28/what-is-quartz.html. Where would I find it - and what are its functionalities ?

There was a web-based gui that was built some years ago but fell out of maintenance. It can be found in the SVN repository, and should mostly work, but it is fairly rudimentary.

Terracotta is preparing to invest in building a new maintenance Panel, but that is some time off.

With Quartz's API, it's pretty easy to create your ow web pages that provide the functions that you want (e.g. listing jobs, deleting/pausing jobs, etc.).

sejer wrote:

- as far as I have been able to determine, jobchaining can be established either in terms of coding ones own listeners to start one job on completion of another - or by direct triggering of the next job as the last step of the execute() method of the previous job. What about more complex dependencies, where job C depends on the completion of jobs A and B. How is this handled ? And can jobchains be "configured" rather than coded ?

Those are really your options. Workflow has been out-of-scope of the project up until now. There is a simple chaining listener that ships with Quartz.

Listeners can track which jobs have completed with which statuses, and issue scheduling commands based on what they see.

Some people couple various open source workflow engines with Quartz.

I've seen implementations that use a base abstract Job class that knows who to communicate with a workflow engine or state machine to decide what if anything to trigger next. The execute() method is implemented on this class to call an abstract template method such as doExecute() and then makes the workflow/state checks and moves things along. The extending Job class puts its work in the template doExecute() method.

sejer wrote:

- handling of jobs that end in error and needs to be rerun, potentially after correcting data or fixing the code. How can this be achieved ? For instance, if the job is in the middle of a jobchain where the first job is triggered by the scheduler and a trigger and has completed successfully with triggering the second job in the chain as the last step in its execute() method. If this second job then fails. what means exist to rerun this second job and have the rest of the jobs in the chain executed ?

Typically the listener (or whatever other mechanism) that handles the chaining will only trigger the next job if the current one completes successfully. If the job throws an exception, the scheduler itself may auto-ree-xecute the job (immediately) - depending upon the exception (see JobExecutionException).

Typically the best practice (even without chaining) is for the Job to catch and handle all exceptions/errors within itself. This is because it is extremely difficult for the scheduler to know what the right thing to do is. A quite common approach is to have the job log errors or send alerts in some other way, and then re-schedule itself to be triggered some time later (and exit without throwing an exception).

Private message me and I'll send you a draft version of a document that is being prepared to add to the quartz website's docs section.

This means one of:

* the quartz tables have not been created in the database
* you configured quartz to connect to the wrong database (or with the wrong db user)
* The tables have been created but they have been created with a prefix other than "qrtz_" and the configuration hasn't been set to use something other than "qrtz_".

It works on Java 6 just fine. That's what most users use.

AHA! That's likely it.

How are you starting quartz up? Are you using the initializer servlet or context listener in the web xml?

If so there is a config parameter: "start-delay-seconds" that you could set.

If you're starting the scheduler some other way, there is the scheduler.startDelayed() method you could use instead of scheduler.start().

Do you see any logging about misfire handling during the restart? If so, can you post that logging?

Do the simple triggers have a repeat count and interval set on them?

What misfire instruction is set on them?

And you are absolutely sure volatility is set to false?

Also, setting your misfire threshold to a larger value (large enough that all 300 jobs can execute within that time period) would prevent the ones that have already fired from being updated to a new fire time when the misfire is detected (because the misfire won't be detected).

Also, what version are you running? And which JobStore are you using?

The 1.7.1 release corrected a problem with the order of misfire handling in the JDBC JobStore.

Seems like a silly setup. Why create so many jobs with frequently repeating triggers if there are so few threads in your pool that they have no hope of ever all running?

Anyway, you might try setting the misfire instruction of the triggers to MISFIRE_INSTRUCTION_DO_NOTHING.

Could you post your properties file, or at least specify whether you're using JobStoreTx or JobStoreCMT ?

Also, do your triggers fire often? (could they be firing while the retrieval is taking place?)

Did you read the overview?

http://quartz-scheduler.org/overview/index.html