Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Yes, as long as your scheduler names are distinct, they can share the same set of tables.

If the scheduler names need to be the same, but you don't want them to act as a cluster (sharing the data), then you need two sets of tables (with different table prefixes, or in different database spaces).

That should be quite easy to figure out yourself from the docs and examples:

http://quartz-scheduler.org/documentation/quartz-2.2.x/tutorials/crontrigger

(For example, this doc includes an example for "Fire at 10:15am on the third Friday of every month" - pretty much what you need).

Quartz does not intend for your jobs to "hog" a worker thread for the life of the application, but it also shouldn't do anything too detrimental if you do that. You'd want to think hard about what attributes to set on the job and trigger related to that - such as whether it should disallow concurrent executions, request recovery, etc. Should the trigger be repeating - probably not? If so, what does that mean if the job is running forever once it is running? But then you have to schedule the job new each time the app runs.

In short, it isn't recommended usage of Quartz, but you should be able to make it work fine. However make sure you have enough other worker threads for other scheduled jobs to run on, since you'll be tying one up.

Best guess is that something is going wrong with transactions/locking. The three DBs you are using happen to have that as their weak points.

With MySQL are you using InnoDB tables? With DB2 are you using serializable tx isolation level (i see the property set to false in your posted config)? With HSQL are you using MVCC=TRUE on the db coinfig ?

What are the odds of getting you to try with Quartz 2.2.0 ? There was a race condition fixed w/respect to blocked triggers when an exception occurs on the db connection. Small chance you're hitting that.

As soon as the trigger fires, and the job get executing, the trigger is updated to its new next fire time - so by time your job is in its execute method, the trigger is advanced.

If your job is not recoverable, then at that point it is assumed that anything that Quartz needs to do for that firing of the job is already finished.

Misfire events would occur if no node is able to fire the *next* firing of the trigger on time.

It is the node executing the job that initiates the job completion event - so if that node has died, there will be no such event, and in fact the job didn't complete.

The triggerComplete event occurs after the trigger fires for its last time (there is no repeat to occur based on its schedule). This event won't occur if there is a next time.

I'm guessing you're looking for an event to occur if the node executing a non-recoverable job fails. There is no such existing event.

You could create a custom thread pool implementation to allow for changing the size.

Note though that the semantics of that interface must be met very rigidly.

Probably it is misfire handling that is updating the trigger.

You can listen for a misfire event.

Once the scheduler is started there are very few settings that can be changed, so yes, you'll almost certainly need to restart it.

Which settings are you wanting to change?

Definitely sounds like a problem with the JVM.

Since the expression is stored that way in the DB, quartz keeps finding it. You're going to need to edit the value in that db column - replace it with a new expression.

I'd suggest replacing it with either '0 0 0 ? * SUN#5' or '0 0 0 ? * MON#5' .

Then you'll probably want to create a new trigger (related to the same job) that has the other of the two expressions. Then you'll end up with firings on the 5th sundays and the 5th mondays.

Ah! : http://forums.terracotta.org/forums/posts/list/8394.page

The column can be added such as this:

for oracle: ALTER TABLE QRTZ_FIRED_TRIGGERS ADD COLUMN SCHED_TIME NUMBER(13) NOT NULL;
for postgresql: ALTER TABLE QRTZ_FIRED_TRIGGERS ADD COLUMN SCHED_TIME BIGINT NOT NULL;
for MySql: ALTER TABLE QRTZ_FIRED_TRIGGERS ADD COLUMN SCHED_TIME BIGINT(13) NOT NULL;

etc.

Gah! somehow it got dropped from the notes between the draft and what got published. Thanks for pointing this out.

The fired_triggers table has that information. if you're just going to read from the table (not insert/update) it should be safe.

It should only try to insert a row in that table if one does not already exist - which would mean the first time running a scheduler instance against that set of tables with that scheduler name.

Does this problem happen repeatedly? I can't imagine how it could, unless you're 1) deleting/emptying the tables between runs, and 2) starting multiple instances at the same time and somehow encountering a strange race condition that isn't handled as expected.