Terracotta Discussion Forums

When Quartz is initialized it logs information about its configuration - including naming which jobstore it is using. Look for that to confirm your setup.

See trigger.setMisfireInstruction(..)

RAMJobStore does not support clustering.

You need to use JDBC JobStore or TerracottaJobStore.

There's no magic available. There are serious limitations of the Java platform at play with such issues.

See InterruptableJob interface.

No, you'll have to retrieve the job.

That's right, it can only be used with TC JobStore.

An common solution if wanting to stick with JDBC JobStore is to create multiple schedulers. Only start() the instance on the node you want to run the jobs, and do not call start() on the nodes where you want to do the scheduling but don't want it to run.

I see how you are creating the scheduler within your webapp, but how are you going about scheduling jobs, as you are in your test program (with the main()) method?

Using CalendarIntervalTrigger instances will give you the functionality you want.

That's right, there's no way to do this except on a node-by-node basis.

How are you setting the content of the map? Are you really setting it on the trigger's job data map, or on the job's? If the latter you need to retrieve the job detail and call getJobDataMap() on that.

Many use Quartz clustered with PostgreSQL and have no issues.

Why are you sitting this property:
Code:

 org.quartz.jobStore.txIsolationLevelSerializable = true

???

There should be no need, and it directly relates to your error message.

Are you using a custom JobFactory implementation?

From the logging, it sure looks just like you have more than one scheduler instantiated and running.

The solution is to use non-repeating triggers, and have the job re-schedule itself as it is completing (before exiting the execute() method).

This is highly dependent upon hardware, network and OS (OS's thread scheduler, number of CPU cores, all sorts of things).

Really it would be best to do a proof-of-concept on your system architecture to know for sure. Around 100/sec isn't out of the question.

Quartz is most adapted to scheduled jobs, as opposed to a job queuing type use case.