Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

hello,
not sure if that would solve your problem, but how did you migrate from oracle ? I mean did you use such a sql script (http://svn.terracotta.org/svn/quartz/branches/quartz-2.2.x/docs/dbTables/tables_sybase.sql ) to set up your database ?
Anthony

Hello,
You are right, this is a bug; I created a Jira :
https://jira.terracotta.org/jira/browse/QTZ-313
you can follow it (you will to register a free account), or even provide a patch to fix it (provided it includes unit tests are validating the fix) (you will need to sign the Terracotta contributor agreement : http://docs.terracotta.org/confluence/download/attachments/27918462/Individual+Contributor+Agreement.pdf?version=2) or wait for the resolution ...
Thank you very much bmk028 for discovering this bug !
Anthony

Hello,
quartz-api is using 1 for January etc... to 12 for December.
You should probably use :
Code:

db = db.inMonthOnDay(cal.get(Calendar.MONTH)+1,cal.get(Calendar.DAY_OF_MONTH));

in your code

sangram wrote:

If there is a single job that needs to be executed 4-5 times in a time range of 3mts, so will these jobs be executed asynchronously?

yes, they won't wait for each other, the scheduler will decide, based on the triggers definitions, of when to execute them and will use a worker thread to do so

sangram wrote:

Also increasing the threadcount from default "4" to more specifies that for every jobexecution a thread is dedicated. If 4 triggers on a single job are scheduled at a time, it means all the 4 jobs are executed asynchronously(parallely) as per the java Thread concepts.

yes, in parallel.
You should definitely try it for yourself; use one the Quartz examples (https://svn.terracotta.org/repo/quartz/branches/quartz-2.2.x/examples/) and tweak it with several triggers, to reproduce your scenario; then in debug mode in your ide, have a look at the threads and the way they behave when you set a breakpoint in your job execute method.

Quartz uses Worker threads to execute the jobs.
If your job (the execute method) takes 10 min. to execute, the worker thread associated to it will be retained for 10 min; so it is synchronous in that way.
That said, you can can control the number of threads available using org.quartz.threadPool.threadCount or you could create and start a new Thread in the execute method of your job and implement a callback, to have an asynchronous job execution

hello,
did you have a look at the cron trigger doc ?
http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/crontrigger

look at the L argument, last day of month, and provide to your users the ability to choose between 30 or last day of month

hello,
did you try to use the context of your job ? for example something like context.getPreviousFireTime()
that way you could check if you're recovering or not, and take the appropriate actions ?

I'm not sure you can do that...
why can't you use 2 triggers ?

hum that sounds strange...
did you try, to debug, to provide an absolute path, or to copy the job definition file in several classpath-related locations ?

hello,
did you specify quart_data.xml instead of quartz_data.xml in your properties file ?

hello,
I don't think that would be a problem to increase this column size, it is just holding the cron expression for your job.
Is there a reason 120 chars are not enough for your cron expressions ?

you can use log4j-over-slf4j to be able to provide a log configuration a la log4j to quartz : http://www.slf4j.org/legacy.html

hello,
did you try to ask the quartz.net community ? http://quartznet.sourceforge.net/
this forum is focusing on problems related to quartz for the java platform

a quartz rest agent is currently work in progress (there is already some code regarding this feature in trunk); we should be using jackson for exposing jobdetails and triggers in a json format.

hello,
you can have the job re schedule itself
Code:

  public void execute(JobExecutionContext context) throws JobExecutionException {
         //re configure your trigger according to your strategy
         //your algorithm may need to know how often it retried, 
         //you could save such info in the context.getJobDetail().getJobDataMap().put(key, value);
         context.getScheduler().scheduleJob(context.getTrigger());
     }