Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

The most likely (almost always) cause of a trigger going to ERROR state is that the job class cannot be loaded or newInstance() fails (no puplic no-arg constructor).

Perhaps the job class is not in the classpath on all nodes (where it fails) - but is on some (where it succeeds).

What job store are you using? Do you have the "wrap jobs in user transaction" setting set to true? from what context are you unscheduling the job (e.g. from within a job for from inside an application action, or... ).

You are storing the job before adding the listener to it, hence the copy that is retrieved from storage has no listener on it. (You are adding the listener to your copy of the job, not the scheduler's copy).

unscheduleJob does remove the trigger. If it doesn't for you, something is going wrong. Perhaps a transaction problem?

yes, retrieve the job, modify it, and then add it again to the scheduler, with the "overwrite" flag set to true.

Is there no error in the logs before this one? Per the exception, something has closed the connection.

Does your TEST environment have multiple nodes? And if so, does your quart.properties file specify isClustered=true ?

There are start scripts (*.bat, *.sh) in each example directory of the main distribution.

As published several times in documentation, there are NO guarantees of Quartz's behavior if you directly manipulate the data in the tables, vs. using the Quartz API to submit the jobs/triggers.

I you need another application to schedule jobs (outside of the JVM where the scheduler is running and jobs will execute), setup a scheduler in that other app with the same database config (so it is pointing at the same tables), but do not call start() on that scheduler. You can then use the scheduler api to manage scheduling data, but not jobs will be triggered/execute on that instance.

You can change it through configuration in the quartz.properties file.

Code:

 org.quartz.scheduler.userTransactionURL: UserTransaction

Are you setting the request recovery flag on the JobDetails ?

Yes, a number of users run with 200 to 500 worker threads.

How this behaves depends a lot on the nature of your jobs. If they are short-lived jobs (i.e. their execution only takes a second), then such a number of threads will cause serious lock contention in the Quartz internals (locks around the integrity of the job/trigger data). But if the jobs take a while to run, and particularly if they perform blocking operations (e.g. network i/o) then you are likely to benefit from a large number of threads.

Experimentation with your particular setup and jobs will probably be key to finding the "sweet spot".

I highly doubt this is a bug relating to quartz, but is rather something to do with your setup of applications and log4j. Seems likely to be classpath problems in the apps you are executing via quartz.

Are you using an App Server with a TM? Are you starting a UserTransaction before invoking methods (and committing after)?

There's nothing special you should have to do/setup other than the above.

e.g.:

UserTransaction utx = context.lookup("java:comp/UserTransaction");

utx.begin();

// do stuff, e.g. with hibernate

scheduler.scheduleJob();

// do stuff, e.g. with hibernate

utx.commit();

Of course the begin(), ccommit() etc on the UserTransaction may also be done "behind the scenes" by Hibernate, depending upon how you are using it's transaction and session model.

Quartz must not be using your quartz.properties file, but must instead be "falling back" to the default one that is within the quartz.jar.

You could verify this by changing the name of the scheduler in your properties file, and seeing if the default name still shows up.

This is almost certainly a classpath problem. Make sure your quartz.properties is in your classpath before the quartz.jar, or that you give the full path to your quartz.properties file to the initializer.