Quarkus: Quartz extension does not store job on db.

Created on 28 Jul 2020 · 3Comments · Source: quarkusio/quarkus

Describe the bug
I'm trying to configure the quartz extension to work with database but it seems it always fall back to the default behaviour which is RAMJobStore.
Quartz tables are present but always empty, the only tables filled are "QRTZ_SCHEDULER_STATE" and "QRTZ_LOCKS".

This is the startup log:

2020-07-28 11:22:21,305 DEBUG [org.qua.imp.StdSchedulerFactory] (Quarkus Main Thread) Using default implementation for ThreadExecutor                                                                                                  
2020-07-28 11:22:21,305 DEBUG [org.qua.sim.SimpleThreadPool] (Quarkus Main Thread) Job execution threads will use class loader of thread: Quarkus Main Thread                                                                          
2020-07-28 11:22:21,313 DEBUG [org.qua.cor.QuartzSchedulerThread] (Quarkus Main Thread) QuartzSchedulerThread Inheriting ContextClassLoader of thread: Quarkus Main Thread                                                             
2020-07-28 11:22:21,314 DEBUG [org.qua.cor.SchedulerSignalerImpl] (Quarkus Main Thread) Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl                                                           
2020-07-28 11:22:21,314 DEBUG [org.qua.cor.QuartzScheduler] (Quarkus Main Thread) Quartz Scheduler v.2.3.2 created.                                                                                                                    
2020-07-28 11:22:21,315 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) JDBCJobStore threads will inherit ContextClassLoader of thread: Quarkus Main Thread                                                                  
2020-07-28 11:22:21,315 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) Using db table-based data access locking (synchronization).                                                                                          
2020-07-28 11:22:21,316 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) JobStoreCMT initialized.                                                                                                                             
2020-07-28 11:22:21,316 DEBUG [org.qua.cor.QuartzScheduler] (Quarkus Main Thread) Scheduler meta-data: Quartz Scheduler (v2.3.2) 'QuarkusQuartzScheduler' with instanceId 'ciccio1595928141305'                                        
  Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.                                                                                                                                                                
  NOT STARTED.                                                                                                                                                                                                                         
  Currently in standby mode.                                                                                                                                                                                                           
  Number of jobs executed: 0                                                                                                                                                                                                           
  Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 25 threads.                                                                                                                                                             
  Using job-store 'org.quartz.impl.jdbcjobstore.JobStoreCMT' - which supports persistence. and is clustered.                                                                                                                           

2020-07-28 11:22:21,316 DEBUG [org.qua.imp.StdSchedulerFactory] (Quarkus Main Thread) Quartz scheduler 'QuarkusQuartzScheduler' initialized from an externally provided properties instance.                                           
2020-07-28 11:22:21,317 DEBUG [org.qua.imp.StdSchedulerFactory] (Quarkus Main Thread) Quartz scheduler version: 2.3.2                                                                                                                  
2020-07-28 11:22:21,317 DEBUG [org.qua.cor.QuartzScheduler] (Quarkus Main Thread) JobFactory set to: io.quarkus.quartz.runtime.QuartzScheduler$InvokerJobFactory@64c26213                                                              
2020-07-28 11:22:21,321 DEBUG [org.qua.imp.jdb.StdRowLockSemaphore] (Quarkus Main Thread) Lock 'STATE_ACCESS' is desired by: Quarkus Main Thread                                                                                       
2020-07-28 11:22:21,322 DEBUG [org.qua.imp.jdb.StdRowLockSemaphore] (Quarkus Main Thread) Lock 'STATE_ACCESS' is being obtained: Quarkus Main Thread                                                                                   
2020-07-28 11:22:21,322 DEBUG [org.qua.imp.jdb.StdRowLockSemaphore] (Quarkus Main Thread) Inserting new lock row for lock: 'STATE_ACCESS' being obtained by thread: Quarkus Main Thread                                                
2020-07-28 11:22:21,323 DEBUG [org.qua.imp.jdb.StdRowLockSemaphore] (Quarkus Main Thread) Lock 'STATE_ACCESS' given to: Quarkus Main Thread                                                                                            
2020-07-28 11:22:21,323 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) Adding TriggerPersistenceDelegate of type: org.quartz.impl.jdbcjobstore.SimpleTriggerPersistenceDelegate                                             
2020-07-28 11:22:21,323 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) Adding TriggerPersistenceDelegate of type: org.quartz.impl.jdbcjobstore.CronTriggerPersistenceDelegate                                               
2020-07-28 11:22:21,324 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) Adding TriggerPersistenceDelegate of type: org.quartz.impl.jdbcjobstore.CalendarIntervalTriggerPersistenceDelegate                                   
2020-07-28 11:22:21,324 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) Adding TriggerPersistenceDelegate of type: org.quartz.impl.jdbcjobstore.DailyTimeIntervalTriggerPersistenceDelegate                                  
2020-07-28 11:22:21,329 DEBUG [org.qua.imp.jdb.StdRowLockSemaphore] (Quarkus Main Thread) Lock 'STATE_ACCESS' returned by: Quarkus Main Thread                                                                                         
2020-07-28 11:22:21,330 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) ClusterManager: Check-in complete.
2020-07-28 11:22:21,330 DEBUG [org.qua.imp.jdb.JobStoreCMT] (Quarkus Main Thread) JobStore background threads started (as scheduler was started).
2020-07-28 11:22:21,330 DEBUG [org.qua.cor.QuartzScheduler] (Quarkus Main Thread) Scheduler QuarkusQuartzScheduler_$_ciccio1595928141305 started.
2020-07-28 11:22:21,330 DEBUG [org.qua.imp.jdb.JobStoreCMT] (QuartzScheduler_QuarkusQuartzScheduler-ciccio1595928141305_MisfireHandler) MisfireHandler: scanning for misfires...

Expected behavior
When i create a job i'm expecting that is persisted inside the quartz table.

Date startDate = Date.from(schedule.getStartDate());
SchedulerFactory schedulerFactory = new StdSchedulerFactory();
Scheduler scheduler = schedulerFactory.getScheduler();
scheduler.start();

JobDataMap jobData = new JobDataMap();
jobData.put("schedule", schedule);

JobDetail job = JobBuilder.newJob(ScheduleJob.class)
    .withIdentity(schedule.getJobId())
    .setJobData(jobData)
    .build();
Trigger trigger = TriggerBuilder.newTrigger()
    .withIdentity(schedule.getJobId())
    .startAt(startDate)
    .withSchedule(SimpleScheduleBuilder.simpleSchedule().withMisfireHandlingInstructionIgnoreMisfires())
    .build();

scheduler.scheduleJob(job, trigger);

Actual behavior
On job creation quartz is initialized again as RAMJobStore and job are not persistend inside the quartz table.

```2020-07-28 11:27:58,929 DEBUG [org.qua.imp.StdSchedulerFactory] (executor-thread-1) Using default implementation for ThreadExecutor
2020-07-28 11:27:58,929 DEBUG [org.qua.sim.SimpleThreadPool] (executor-thread-1) Job execution threads will use class loader of thread: executor-thread-1
2020-07-28 11:27:58,932 DEBUG [org.qua.cor.SchedulerSignalerImpl] (executor-thread-1) Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
2020-07-28 11:27:58,932 DEBUG [org.qua.cor.QuartzScheduler] (executor-thread-1) Quartz Scheduler v.2.3.2 created.
2020-07-28 11:27:58,932 INFO [org.qua.sim.RAMJobStore] (executor-thread-1) RAMJobStore initialized.
2020-07-28 11:27:58,932 DEBUG [org.qua.cor.QuartzScheduler] (executor-thread-1) Scheduler meta-data: Quartz Scheduler (v2.3.2) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 threads.
Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.

2020-07-28 11:27:58,932 INFO [org.qua.imp.StdSchedulerFactory] (executor-thread-1) Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
2020-07-28 11:27:58,933 DEBUG [org.qua.imp.StdSchedulerFactory] (executor-thread-1) Quartz scheduler version: 2.3.2
2020-07-28 11:27:58,933 INFO [org.qua.cor.QuartzScheduler] (executor-thread-1) Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.


**To Reproduce**
Steps to reproduce the behavior:
1. Start quarkus with provided properties
2. Create a job

**Configuration**
```properties
# Quartz configuration
quarkus.quartz.clustered=true
quarkus.quartz.store-type=db
quarkus.quartz.force-start=true

# Datasource configuration.
quarkus.datasource.db-kind=mysql
quarkus.datasource.username=${MYSQL_USER:root}
quarkus.datasource.password=${MYSQL_PASSWORD:password}
quarkus.datasource.jdbc.url=jdbc:mysql://${MYSQL_HOST:localhost}:${MYSQL_PORT:3306}/${MYSQL_DB:quartz}

Environment (please complete the following information):

Output of uname -a or ver: Linux ciccio 5.4.0-7634-generic #38~1595345317~20.04~a8480ad-Ubuntu SMP Wed Jul 22 15:13:45 UTC x86_64 x86_64 x86_64 GNU/Linux
Output of java -version: openjdk version "11.0.8" 2020-07-14
Quarkus version or git rev: 1.6.0.Final
Build tool (ie. output of mvnw --version or gradlew --version): Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)

arescheduler kinbug triaginvalid

Source

dididado

Most helpful comment

Thanks for the reply mkouba, i did miss that... Now it works as expected!

dididado on 28 Jul 2020

🎉1 👍1

All 3 comments

/cc @mkouba, @machi1990

quarkusbot on 28 Jul 2020

On job creation quartz is initialized again as RAMJobStore and job are not persistend inside the quartz table.

It is initialized again because you create a new Scheduler instance manually:

SchedulerFactory schedulerFactory = new StdSchedulerFactory();
Scheduler scheduler = schedulerFactory.getScheduler();
scheduler.start();

You should inject the existing org.quartz.Scheduler instead. See for example https://quarkus.io/guides/quartz#scheduling-jobs-programmatically. Alternatively, you can obtain a scheduler instance via programmatic lookup: Arc.container().instance(org.quartz.Scheduler.class).get().