CODEWITHSUNDEEP
javaspringspring-bootquartz-scheduler
N4zroth
N4zroth

Reputation: 1366

Spring Boot - @EnableScheduling combined with spring-boot-starter-quartz

We have a project that uses somewhere around ten Quartz jobs via the aforementioned dependency. Everything seemed to work fine for a while but we have two jobs that just randomly stop working (all jobs are scheduled to run every five seconds). Our mitigation strategy was to migrate these jobs to Spring's 'own' scheduling as they do not require any input data. After adding @EnableScheduling and the appropriate @Scheduled annotation, they work fine and run every five seconds. The problem is that now, the 'old' Quartz jobs seemed to have stopped working (at least in our integration tests, they wait 20 seconds for an execution). The Quartz jobs just never fire. When increasing the timeout, the Quartz jobs sometimes start about 30 seconds after being scheduled. While they are running, the Spring jobs seem to wait. We have tried setting the thread count for both Quartz and Spring to > 50 but nothing seems to help. We're somewhat out of ideas, does anybody know a solution?

We're using Spring Boot 2.3.3. and the latest Quartz, 2.3.2.

Thanks.

Upvotes: 0

Views: 583

Answers (1)

N4zroth
N4zroth

Reputation: 1366

Ok so the problem seems to be with our @Transactional management - we seem to have somehow acquired a lock that blocks Quartz's scheduler from finding triggers that were scheduled for immediate execution (Quartz trigger does not fire immediately seems to have the same problem, but unrelated to Spring scheduling). We 'fixed' the problem by setting

spring.quartz.properties.org.quartz.scheduler.idleWaitTime=5000

This is obviously not a fix but instead of waiting for 30 seconds (the default for Quartz's idle wait time which initially made the jobs only being executed after said time), the scheduler only waits for five seconds to search for triggers after not finding one. This makes our immediate jobs trigger five seconds late but that isn't a problem in our use case.

Of course, this isn't the real solution, refining our @Transactionals would probably be the correct fix but we cannot do that right now, maybe sometime in the future.

Why the problem started ocurring after @EnableScheduling and not beforehand, we have no idea.

Upvotes: 0

Related Questions