Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

For usage help, general questions:

https://groups.google.com/forum/#!forum/quartz-scheduler

To participate in the development of Quartz (no usage questions!):

https://groups.google.com/forum/#!forum/quartz-scheduler-dev

General Quartz community info:

http://quartz-scheduler.org/community

For usage help, general questions:

https://groups.google.com/forum/#!forum/quartz-scheduler

To participate in the development of Quartz (no usage questions!):

https://groups.google.com/forum/#!forum/quartz-scheduler-dev

General Quartz community info:

http://quartz-scheduler.org/community

For usage help, general questions:

https://groups.google.com/forum/#!forum/quartz-scheduler

To participate in the development of Quartz (no usage questions!):

https://groups.google.com/forum/#!forum/quartz-scheduler-dev

General Quartz community info:

http://quartz-scheduler.org/community

For usage help, general questions:

https://groups.google.com/forum/#!forum/quartz-scheduler

To participate in the development of Quartz (no usage questions!):

https://groups.google.com/forum/#!forum/quartz-scheduler-dev

General Quartz community info:

http://quartz-scheduler.org/community

I'm curious to know if you are actually using the scheduling features (e.g. that the job needs to run at a particular time) - or if you are using Quartz more as just a job queue (just run the jobs as quick as you can).

"fire-up" in that quoted sentence means start(). Perhaps that should be made more explicit.

Clustering gives you High Availability (if the quartz instances are in on different machines). It also brings scale, in that the jobs can execute on more machines - which may be important if your jobs use a lot of system resources.

Note that you can define listeners in the quartz.properties, and then Quartz will instantiate them on startup - but then are are limitations in that if they needed to be wired up by your application, they weren't.

The applications may share the same JVM, but they likely have different class loader space, and hence the Quartz instances each obtains won't be the same instances.

You can have the two apps share the same JobStore database by pointing their configs at the same database. BUT you must realize that this lets them share data, but they are distinct schedulers. Hence you must opt for one of the following setups:

option 1- Turn on the "isClustered=true" property for the jobstore. And then the jobs will execute within both schedulers (whichever gets around to executing it first).

option 2- Do not turn on clustering, but only call scheduler.start() on the scheduler in the application where you want the jobs to execute. The other application's scheduler (without start() called on it) can still store (schedule) and retrieve jobs, etc. it just won't execute any.

Workflow features have been out of the scope of Quartz so far, though it is a frequent topic.

There is a FAQ entry:

http://www.quartz-scheduler.org/docs/faq.html#FAQ-chain

You may also want to look at:

http://www.quartz-scheduler.org/docs/api/org/quartz/listeners/JobChainingJobListener.html

You have to re-register the Listener with the scheduler instance each time it is created (listeners themselves are not persisted - they are considered to be part of your application, and therefore your application's responsibility to manage their lifecycle).

The scheduler does remember/persist the name of the listener associated with the trigger. -- And hence you are running into the problem that after restarting the application the trigger fires and the scheduler knows to look for a listener with a particular name, but none has been registered with the newly instantiated scheduler.

There's no "free" way to achieve this.

But you could do one of the following:

1- use a trigger than repeats every N seconds, have the job unschedule itself if it "fails" (whatever that means to it).
2- use a single-fire simple trigger to fire the job the first time. have the job schedule itself with a new (single-fire) trigger if it "succeeds".
3- a variation of either #1 or #2 where a JobListener does the work of scheduling/unscheduling the job.

Yes, that's true.

The OOM can't be caused by Quartz, unless you have very low available memory.

Furthermore, if you are experiencig OOM Errors, you should expect all sorts of erratic / unpredictable outcomes of the things going on within your JVM - as threads will be dying at random points in their work.

Lastly, it's normal for only one trigger to be "acquired" at time. Quartz the acquired state means that it has been identified as the next trigger to fire (based upon its next fire time and priority).

Actually, it's possible now, just not elegantly.

Node-specific features don't currently exist, though they are on the road map.

For now, you'll have to use two instances of Quartz per node. --- Essentially configuring two clusters.

One cluster of schedulers will exist on all nodes, but only have start() invoked on the scheduler on 2 nodes.

The other cluster of schedulers will exist on all nodes, but only have start() invoked on 8 nodes.

Jobs running on either node should be able to use either scheduler (whether start()ed or no) to schedule jobs.

Only the nodes that have start() called on them will execute jobs.

What do you mean by "the session"?

If you mean the scheduler API, then it's simple: jobExecutionContext.getScheduler().