Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

see the methods on TriggerUtils that compute future fire-times of triggers... they're perfect for enabling the type of tests you're inquiring about.

This is computationally intensive (more so than may be evident at your first thought) and there are many different possible desired semantics of such, and hence quartz does not provide a high-level api for doing this.

Your will basically need to iterate over every trigger in the scheduler, and determine whether it will fire within your time range. There are some helper methods on the TriggerUtils class that will compute future fire times of a trigger (don't just look at the trigger's nextFireTime - because the trigger may repeat a number of times... one or more of which may occur within your time range of interest, or perhaps the repeat interval may cause the trigger's firings to completely skip over your time range of interest).

http://www.quartz-scheduler.org/docs/configuration/ConfigJobStoreTX.html

Why are you not using the Oracle Delegate in your Oracle setup?

Also, I'd definitely recommend upgrading to 1.6.6. It should drop right in place, and 1.6.0 was a major revision, for which several issues were patched in subsequent releases.

I'm not fully sure I understand your question... but here goes.

If you have a scheduler that is configured to use the jdbc jobstore, then any jobs and triggers you schedule will be placed in the database. If your application restarts, so long as you create a scheduler pointed at the same database tables, all of those stored jobs and triggers will resume.

Do NOT ever write data to the database tables yourself. Always use the scheduler API.

Thanks! Those API suggestions are actually already on the "2.0" roadmap.

Sorry, I'm not sure what else to suggest.

The stack trace clearly shows that the connection reset, and your description of it being the first job to run after overnight helps support that idea that the idle connection goes bad.

Having the validation query should clear that up though.

I suggest reviewing DBCP settings.

I honestly don't know. There haven't been huge API changes, so if it doesn't work with the latest version, it should be a matter of simply fixing a few lines of code and recompiling.

Looks like the physical network connection fails over night due to no activity timeout.

Do you have a validate connection query set in your configuration? That would detect the problem and re-create a new connection before the datasource hands the connection out to Quartz for usage.

As an FYI,

A JobFactory impl that reflectively sets properties on the Job (based upon JobDataMap contents) CAN be used by setting the job factory in your quartz.properties to "org.quartz.simpl.PropertySettingJobFactory".

Code:

 org.quartz.scheduler.jobFactory.class = org.quartz.simpl.PropertySettingJobFactory

The web app is currently long out of maintenance.

We hope to revive it (or something like (and better) than it in the near future).

Quartz ships with a QuartzServer class, that fires up Quartz as a standalone application. You can configure it (with quartz.properties) to point to a database where the jobs are stored. The jobs can be inserted into that database by another process by:

1- using the rmi features of quartz from another process, and using the quartz API
2- instantiating a scheduler within another process (e.g. webapp), also pointing it to the same database, but NOT start()ing that scheduler instace, and the using the quartz api to schedule jobs.

Answer: Data corruption will occur.

And yes, if you have multiple scheduler instances pointed at the same DB, but only one has been started, then you will be OK.

This should work -- Just be ASOLUTELY sure that you do NOT start() the scheduler instance that is not being used to execute jobs. ( Do not directly write scheduling info to the database, use the scheduler api to insert them).

If you start two more more instances, and "clustered" is not set to true, and/or the clocks are not sync'd, you will get data corruption.

There are so many possible behaviors for such situations that Quartz does not currently offer any for free.

It should be very easy to do this manually within the job itself. -- The JobExecutionContext passed to the job has a handle to the scheduler, jobdetail and trigger. You can simply make a new trigger, name the running job, and call scheduler.scheduleJob().

james