Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

The monitor is not compatible with new versions of ehcache. Nor is it on the roadmap to be worked on.

(I have sent a mail to the docs team to make that more clear on the docs page related to the monitor - it does indicate such now, but in a not entirely clear way).

It has been replaced by the REST agent that is included with ehcache, that can be enabled thus:

<ehcache ... >
...
<managementRESTService enabled="true" bind="<ip_address>:<port>"/>
...
</ehcache>

http://terracotta.org/downloads/open-source/destination?name=terracotta-3.7.7.tar.gz&bucket=tcdistributions&file=terracotta-3.7.7.tar.gz

Subject says Quartz 2.2.1 ... message says Quartz 1.6.2 ...

Which is it?

Thanks for pointing out that the docs are now inconsistent in that respect.

The specific method is now here:

http://quartz-scheduler.org/api/2.2.0/org/quartz/impl/triggers/SimpleTriggerImpl.html#updateAfterMisfire(org.quartz.Calendar)

But we should straighten out the docs so the info is up on the public interface.

Looks like a bug in the javadoc 0-11 is what the code accepts for months.

Sounds like you're a bit confused on concepts.

I recommend reading at least the quick-start guide, if not the tutorial:

http://quartz-scheduler.org/documentation/quartz-2.2.x/quick-start

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

What if you move the "start-time-seconds-in-future" up two lines (before repeat-count) ?

Is it actually causing a problem?

It's fine to have (and many people do have) multiple schedulers in one JVM.

You can use any size you want - so long as it is long enough for whatever names you are giving to your triggers/jobs etc.

You are correct : the 4.x line does not support dev console, and the TMC does not yet have support for Quartz. It is a known gap that will be addressed, but has no definite timeline.

In the mean time, you can use the JMX beans (which is what dev-console used) via JConsole or similar tools.

Don't call scheduler.start() on the instance that you do not want to execute jobs on.

Can you please post your Quartz config?

Also, you could try just using the OracleDelegate rather than the weblogic oracle delegate.

There is not enough info above to tell what the actual problem is. Is there any more logging? Any more further "caused by" exception?

You'll have to do the cleanup manually.

The JDBC JobStore is designed as a permanent store. 99.99% of users want that -- e.g. want all of their scheduled jobs to survive an application crash. Hence, if quartz deleted existing data as it started, most everyone would be very angry.

shutdown(true) only waits for currently executing jobs to complete before shutdown. Not for all scheduled firings (but not yet fired) of jobs to occur.

Also, worker threads are only used for executing jobs. Jobs that are waiting for their trigger fire times to arrive are not using threads. When the job's execute method is complete, the thread returns to the pool, ready to execute the next job to have a fire time arrive.